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Abstract 

Obieci-onenied  da-^ba^es  2.-ic  r.\-penex!  sysier-.s  are  emergir.g  ir.  response  :o  a  demand  by 
appiiactior,  developers  for  Lncreased.  less  sn--crkired  modelir.g  power  m  database  systems. 
Such  sy5;err.5  succeed  l'-.  prcMdir.e  the  necessary  tools  and  facmues  for  building 
coopera::\e  v.ork  arr'.ications  bu:  are  luTuted  ui  providing  the  appropnate  object  sharing 
envirorment- 

'V^'e  propose  to  adcL'^ss  the  object  sharj^g  requirements  for  one  such  system  -  Obiec:  Lens 
Object  Ler.b  ir.:erra-.e>  fearjres  z:  r.;.T^r.ex:  system.s.  object-oriented  systems  and  ruie- 
based  agents. 

We  evaluate  various  approaches  tc  object  sharing  (includL-.g  message  passing,  centralized 
object  server  and  dismr^ted  objec:  servers  and  various  scnemes  for  concurrency  conrrol 
and  update  propagation  (lockiLng.  timestampung  >  with  respect  to  the  charaaenstics  desired 
m  Object  Lens  (e  g..  speciaLzatior  hierarchy,  user-mterface.  object  linking,  version  control 
and  combination  of  long  Lnteract;\e  transactions  and  short  automatic  ransacuons). 

We  propose  a  nev.  scheme  for  ■j'jtiating  object  sharing  through  the  exchange  of  electronic 
mail  messages.  Object  protecticr.  is  achieved  by  a  hybnd  scheme  oi  access  control  lists  and 
capability  systems. 

Analysis  of  the  transacuons  in  Object  Lens  reveals  rwo  sets  of  transactions;  (1)  interactive 
transactions  that  require  relatively  weak  consistency  requirements  and  relatively  flexible 
concurrency  control,  ^.d.  ;I;  automate  transactions  that  require  stna  concurrency  control 
requirements.  Vv"e  propose  a  hybnd  locking  and  version  control  concurrency  control 
scheme  that  accomodates  the  two  types  of  transacuons. 
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Chapter  1 
Introduction 

Conventional  record-onented  rclauonal  daxabases  are  rescricted  in  the  i^-id  of  mformanor. 
they  car.  manage.  The\  proMce  da;a  modeiing  and  cransacuon  management  capabii:i:c> 
thai  are  wcli  suited  to  business  daia  processing  but  which  are  not  adequate  for  compuier- 

supponed  coopera:;Ne  \«-ork  appucations  Sjch  L-.creasingI>  important  apphcanons  include 
ccmputer-ajded  desirr..  sofrAare  developmen:.  documema:ion  authonng,  and  anif.cial 
intelligence  knov.  ledge  bases.  Tnese  applicauons  are  T.teracnve  l-.  narjre  and  deal  wi± 
Lmstructured  objects  and  comp:ex  relauonships  among  daia,  people  and  scned'ules. 

Object-oriented  databases  and  hvper.ext  systems  anempt  to  provide  the  platform  to  support 
the  semantic  and  data  models  requL'ed  for  these  applicauons.  Object  Lcjis  [Lai  88.  Maione 
89]  IS  one  such  system.  It  integrates  fearurcs  of  hvTxrtext  and  objea-onented  system.s  to 
provide  a  system  that  may  be  used  to  v^xite  specific  appLicanons  for  retnevmg  and  browsing 
complex  information  such  as  meeting  scheduling,  project  management  and  document 
authonng. 

However,  the  current  implemcmauon  of  Object  Lens  fails  to  suppon  a  key  fearure  of 
cooperative  applications;  Object  Sharing.  Object  Lens  is  currently  a  single-user  system. 
Our  goal  is  to  propose  an  object  sharing  scheme  that  accommodates  the  key  characteristics 
of  Object  Lens  (long  interactive  transactions  combined  with  short  rule-based  transactions, 
complex  objeas,  naive  users,  and  version  maintenance). 
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1.1  Object  Sharing  in  Object-Oriented  Databases  and  Hypertext  Svstems 

Object  ar.c  ir.fomanor.  sharjig  s-.  orjsc.-onented  daubases  and  h>-pcncx;  systems  implies: 

•  Multiple  jser.-  snc-l::  dc  airie  ;c  access  documents  and  destrr.s  created  :?\  oihe: 
users. 

•  CoUaboratL-.e  u?e:s  should  be  able  to  viev.  modi5iCaiions  made  tc  anv  cf  Lbe 
shared  docjmer.t^  c:  desirns  (update  p:opagat;or. , 

•  D^'fere-.".  useri-  uorkir.:  ccr.currer.'jy  should  not  be  able  to  mterfere  v.il-  each 
others  work  (.concurrenc>  conirol;. 


To  surpor.  ob'ect  shar_-.c  these  systems  need  tc  have  a  concurrency  control  scheme,  an 
update  propagator,  sc.-.err.e  and  ar.  object  protection  scheme.  Unforronately  object-oncmed 
databases  and  r.-.-ptr.tx:  s\stem>  car.  not  SL~.pl\  adopt  the  concurrenc\  conrrol  schemes 
(such  as  locidng  and  timestampmg  ■  and  update  propagation  schemes  proposed  and 
implemented  fcr  dtsr-.butec  databases  The  major  problem^s  are  the  different  narure  of  the 
transactions  Ti^nc  \s  shon,  and  the  dif'^'"rnt  nature  of  Lhe  objects  (complex  vs.  simple) 
supported  b>  these  s> stems  anc  traditional  database  systems.  Hov.e\er  these  schemes  can 
be  used  as  the  basis  for  m.ore  adequate  schemes  for  object-onented  databases  and  hv-pertext 
systems" 

Many  object-onented  database?  prototypes  [Purdy  87.  Fishman  8".  Homick  87]  adopt 
variations  of  locking  for  concurrency  control.  Some  systems  use  a  checkin-checkout 
protocol  to  disallcv.  m.Jttple  users  from  accessing  an  object  concurrently.  Existing 
distributed  h\-pcnext  systems  use  either  locking  or  version  control  to  resolve  possible 
conflicts  from,  concurrent  users.  Most  of  these  systems  do  not  support  replication  (multiple 
copies  of  an  obiect;  or  version  maintenance. 
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1.2  The  Proposed  Object  Sharing  Scheme 

V,e  a-'fjc  thai  ihc  cradiuona]  concurrency  concrol  schemes  as  v^eli  as  ihcLj  vananis 
proposed  for  obiect-onenisd  databases  are  not  adequate  for  systerr^s  v.hert  (I  use: 
fnendliness  is  of  major  imponance,  and  (2)  modificanon  may  be  made  to  the  object 
nteractne!)  o:  automatically. 

User  fnendliness  implies  that  (ai  redoing  user  performed  modificaiions  to  an  object  is 
intolerable.  Cb'i  disallowing  users  to  access  objects  for  long  pcnods  oi  iimc  is  again 
intolerable. 

We  propose  a  concurrency  control  scheme  thai  is  a  hybrid  of  locking  and  version  control. 
This  scheme  makes  no  restncnons  on  replication,  i.e..  objects  m.ay  be  repLicaied  and  the 
scheme  would  sell  be  applicable.  It  also  accommodates  the  existence  of  different  versions 
of  an  object. 

We  feel  that  this  scheme  is  suitable  for  object-onented  and  hypenext  applications  that 
emphasize  user  friendliness  and  that  combine  interactive  modiiicauons  through  editing  of 
an  object  form  and  automate  modifications  through  the  execution  of  ruie-bastd 
cxnsacaons. 

1.3  Object  Lens 

Objea  Lens  is  an  mtegraied  (hypertext,  object-oriented  daiabase,  rule-based)  environment 
for  developing  coopcraiive  work  applications.  It  combines  the  fomial  representation  of 
knowledge  (using  strucrures  such  as  frames,  inheritance  networks  and  production  rules)  in 
knowledge-based  systems  with  the  informal  representation  of  infomiation  (unstructure  text 
or  graphics)  in  hypenext  systems  to  present  a  scmiformal  middleground.  Object  Lens  adds 
scmanuc  structure  to  hypenext  nodes  that  allows  the  ease  of  summanzanon  of  objea 
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ccr.:e.-.:>  anc  rs.a:;or.>r.:r>  ar.c  2u:?rr.a:;:  search  ar.d  n-.ampjlatior.  of  a  coliecjor,  of 
objerts  I:  r-.a>  ^e  LS-rc  :?  de^e.?r  sr>er:f;c  applicanor.s  lo:  L'lformatior.  shanr.c.  rer-.f-L".: 
a.-:"'  brrv.  5L-.L  cf  ccmr'.ex  irj'rr-r.a:!??..  meet'-nc  schedding.  projec:  management  and 
documeniatior.  de\elop~.sr.:  (r:>T>er.ex: ..  by  including  CTpiici:  knowledge  on  various 
objects  such  as  difiertr:.  —.essaze  types,  pecp'.e.  task,  mcedngs.  produr^  and  companies. 

Tne  basic  primitives  a\  ailabie  lo  die  programjner  to  build  his  applicauons  are: 

1.  Facilities  i?:  creatine  object  instances  and  object  types  Lirough  a  tem.plate- 
basec  jser  interlace - 

2-  Facilities  tc  modi-f>  objects  by  editLte  the  window  display  corresponding  tc 
the  object 

3.  Facilities  tr  create  r_e-t:2sed  agents  'Jiat  automaucaliy  process  Lnfomianon 
on  behalf  cf  the  user. 

4.  Facilities   tc   collect   objects   toge-ner   into   folders.      The   folders   m.a>    be 
autom.aticall;.  maintained  by  an  agent. 

Featti'''*^  C*^ ar' c*e"" ^T r  c*  O'^'er*  I_en^ 


We  feel  that  tne  follcv.  j-.g  charactenst^cs  of  Object  Lens  liighly  in£uencc  our  choice  of  an 
object  sharjig  scheme 

•  Naive  Users  Orject  Lens  is  geared  toward  non-programjming  users.  Tms 
makes  user-ir.tsrt'ace  a  m.ajor  component  of  the  system..  Tne  uscr-intenace 
model  u'iiuences  what  aspects  of  object  sharing  air  exposed  to  the  user. 

•  Combination  of  .>\utomatic  ancT  Interactive  Modifications  of  Objects 

Objects  may   ei'jier  be  m.odtfied  automancally  by   "rule-based  agents"   or 

interactively  by  a  user  edimg  a  display  wLndow  corresponding  to  the  object. 

•  \ersJon  .Maintenance  As  a  tool  for  unplemcntL-.g  coopcradvc  work 
applicauons,  Ob'ect  Lens  shodd  supp>on  the  Maintenance  of  different  versions 
of  objects. 
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D:s?:bu:ed  Ob'?::  Lgr.s 

Dismbuted  Object  Lens  should  suppon  object  sharjig  bcnveen  various  users  on  the 
ncrwork.  1:  should  suppon  locanon  rransparency,  rephcauon  traiispar;r.c\ .  concurrenc> 
trar.sparcncv'  and  possibly  access  transparency  Users  any  where  in  :he  ncrwork  sho'uJd  be 
able  to  reference  and  dereference  objecis  located  elsewhere  in  the  nerwork.  It  should 
provide  a  mechanism  for  object  protecuon.  It  sho'uld  guard  against  or  resolve  possible 
conflicts  that  anse  because  of  concurrent  access  tc  ar.  object  by  a  number  of  users. 

1.4  Thesis  Approach 

In  this  thesis,  our  main  concern  15  exp'.onng  the  different  issues  mvohed  in  object  sharing 
and  the  possible  solutions  to  these  issues.  We  are  concerned  with  sharjig  object 
"instances"  in  Object  Lens.  V.'e  v.-ii  assume  all  users  have  the  same  object  hierarchies  and 
object  r\-pc  defjiitions,  i.e.  the  PERSON  objec:  universally  means  the  same  Lhuig.  We  will 
not  be  concemed  with  object  type  coercion.  [Lee  88]  explores  the  various  ways  of  doing 
type  translation. 

We  explore  a  large  number  of  dismbuted  systems  (distributed  relational  daiabases, 
distributed  h\pcnext  systems  and  distributed  object-oriented  systems)  to  examine  how 
objea  sharing  is  achieved.  Most  of  these  systems  are  prototypes  and  exjxnmental.  Our 
emphasis  is  on  Lhe  architecture  configuration  of  the  distributed  systems  (centralized  or 
distributed),  the  concurrency  control  schemes  used,  the  protection  schemes  used  and  the 
upxiaie  propagation  schemes  adopted. 

We  specify  the  requirements  and  fearures  of  Distributed  Object  Lens  and  then  study  the 

suitability  of  the  various  techniques  for  the  Object  Lens  environment. 


\^e  fL^.a^i)  S'jr-jr.ar.ze  the  Lradeoffs  betueer.  the  difieren;  techr.iqjes  ir.  the  cor.:t>.:  of 
Obiec:  Lens  ar.c  recommend  the  most  appropriate  aesigr,  for  Distributed  Obiec:  Lens. 

1.5  Thesis  Outline 

Chapter  2  examines  the  var,o-js  arch:tecnires  for  objea  sharing  in  a  distributed  environmien: 
in  the  frameuork  of  the  SerNer-Chen:  Model. 

Chapter  3  descnDe>  vanou>  features  of  a  dismbuted  system-.  I;  surveys  the  vanous 
aJgcr/Jrris  and  schemes  to  acme\Lng  object  sharing  in  a  distributed  envuonmen:.  The 
reieN  ar.:  fearjres  are  conc-rrenc;.  conrrol.  update  propagation  and  protection. 

Chap'^r  -i  preser.-.s  a  bterar^re  s'jr%e>  of  various  distributed  systems  from  relarional 
databases  to  objec:-onentec  datar^ises  to  h\penext  systems.  Tne  emphasis  m  the  surve\  is 
on  the  conc'jrrenc;.  conrro!  m.tcharj.sm.s  adopted,  the  propagation  methods  useJ  and  the 
version  control  schemes  explored. 

Chapter  5  describes  the  fear^res  and  characteristics  of  Object  Lens. 

Chapter  6  describes  the  requirements  for  Distributed  Obiect  Lens.  It  descnbes  object 
shanng  and  protection  in  the  context  of  the  Object  Lens  envTronment.  It  defines  the 
possible  transactions  in  Objea  Lens  and  accordmgly  examines  the  different  techniques  for 
concurrency  control  describing  the  tradeoffs.  A  hybrid  scherrie  best  suitable  for  Distributed 
Object  Lens  is  proposed. 

Chapter  7  summarizes  the  key  tradeoffs  between  the  various  choices  and  schemes  and  then 
presents  Lhe  best  appropriate  approach  for  Distributed  Object  Lens. 
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Chapter  2 
Architectures  for  Object  Sharing 

Users  of  centralized  systems  such  as  maLiframes  are  accustomed  with,  the  idea  of  being  able 
to  share  da*^  and  objects  w-ith  oLher  users  of  the  system.  With  the  ad\ent  of  personal 
computers,  workstaiions  and  nerworts,  Lhe  essential  schemes  and  algorithms  to  suppon 
fcamres  of  object  shanng  needed  to  'c>e  revised  to  v».ork  ir.  such  dismbuted  environments 

The  essential  features  to  object  sharing  in  a  distributed  system  are: 

1.  Allow  muluple  users  a:  various  sues  tc  access  objects  created  b\  any  one  user 
in  lhe  system  (Shared  Access  i.  The  access  allowed  to  these  objects  may 
differ  from  one  user  to  another  {Read,  Wnte.  Delete  )  CProtection'). 

2.  Multiple  copies  of  an  object  may  exist  in  the  system.  The  system  need  to 
ensure  that  all  copies  of  the  object  are  consistent  (i.e.,  the  same")  at  any  point 
in  time.  Consistency  is  achieved  by  propagating  changes  made  to  one  copy  of 
Lhe  objea  to  all  other  copies  (UpHJate  Propagaiion). 

3  Perrrut  users  to  access  object  in  a  multi-programmed  fashion  while  preserving 
the  illusion  that  the  user  is  executing  on  a  dedicated  system.  To  attain  this 
goal,  the  system  should  prevent  modifications  made  by  one  user  from 
interfering  with  reads  or  updates  performed  by  another  (Concurrency 
Control).  The  concurrency  control  problem  is  exacerbated  in  a  distributed 
system  because:  (a)  users  may  simultaneously  access  objects  stored  a:  many 
different  sites  in  a  distributed  system  and  (b)  a  concurrency  control 
mechanism  ai  one  site  cannot  mstantaneously  know  about  interaction  at 
another  sue. 
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Tne.T  aj-f  three  approache;;  ic  cb;ec:  sharing  l".  a  dismbuted  environmer.:  Tr.?  three 
approacnes  are  :Tie5sace-ba5ed,  centraiizec  shared  object  space  and  distributed  snared 
object  space  \^'e  focus  oii:  anention  or  the  locauon  and  maintenance  of  shared  obiects 
V.'t  assume  tr.i-  perscni!  object>  are  located  a:  the  local  site  for  pjcrsonal  use  only. 

A  message-based  approach  suggests  Lha:  object  sharing  could  be  done  through  the  exchange 
of  specialized  electronic  mail  messages.  To  a  large  extent  in  distributed  systems 
information  sharing  is  done  thjough  the  use  of  electronic  mail.  The  suggestion  is  that  this 
could  be  extended  to  incorporate  exchange  and  sharing  of  objects. 

Tne  cenral_zed  approach  suggests  Lhat  shared  objects  be  located  at  a  central  sue  ir.  the 
nerworx.  Lniv;dual  v-ori^staticns  nttd  to  direct  shared  object  access  to  the  centra]  sue. 
Tr.2S  approach  is  h:gbJ>  dependent  on  the  availability  of  the  central  site. 

The  distributed  approach  suggests  that  shared  objects  be  distributed  at  different  sites  m  the 
nerw.o:k    Users  at  different  sues  snouid  'oe  able  to  access  objects  located  at  each  sue. 

Vv'e  present  the  centralized  and  distributed  approach  to  objea  sharing  in  framework  of  a 
Serv'er-Cltent  Model  The  ser\'er  provides  the  required  object  m.anagement  and  objects. 
The  client  is  locate  at  each  woritstation  to  direct  object  requests.  In  the  centralized 
approach,  one  object  server  exists  in  the  distributed  system.  Object  caches  may  be  provided 
a:  the  client  sue  to  improve  object  access.  In  the  distributed  approach  several  objea  servers 
exist  Tnesc  may  be  dedicated  machines  as  in  the  central  approach,  in  which  case  object 
caches  ai  the  client  workstation  may  improve  performance.  Another  option  is  to  locate  both 
the  scr\'er  and  the  client  processes  at  the  workstation.  This  eliminates  the  need  for  a  cache. 

We  examine  in  this  chapter  the  various  possible  implementations  of  each  of  these  schemes 
in  the  context  of  an  object-oriented,  knowledge -based,  hypertext  systems  similar  to  Object 
Lens.  O'ur  sur\e\  is  a  SNTithesis  of  ^preaches  adopted  by  different  systems.  The  major 
fearures  to  keep  in  mind  about  these  systems  arc: 


•  Complix  and  scrru-s3'jc:ured  objects. 

•  Maiupulanor.  ofobiecis  perr'ormed  ihrough  rjie  execuuon  or  use:  inie:aci;or 

•  Triggers  :hai  activaic  processes  uhen  stored  objects  are  modified. 


•  A  rr.ixtiire  of  long  ar.d  shor.  irar.sac'.ions 


Tne  next  chapter  is  reser.ed  to  cxammng  vanojs  aigonthLTis  and  schemes  p'c>posed  for 
concurrency  control,  up>da:c  propaganon  and  protection.  Chapter  4  presents  a  survey  of 
dismbuted  systems  indjcanng  v.  hat  object  sharing  approach  they  use,  and  '-he  concurrency 
control  and  update  propagation  schemes  adopted 

2.1  Message  Based  Object  Sharing 

This  approach  suggests  that  objects  are  shared  ber*een  different  users  by  embedding  them 
in  electromc  m.ail  messages  that  are  then  mailed  through  the  ner*'ork.  Tne  objects  could  be 
either  literally  embedded  into  the  message  or  embedded  li  link  form.  The  first  method 
requires  that  the  receiving  end  extraa  the  object  descnpuon  and  the  unique  objea  identifier 
suprphed  by  the  underlying  system,  and  buCd  a  local  copy  of  the  object  with  the  appropnaic 
unique  object  id.  The  second  method  implies  that  Lhe  sender  insens  only  a  reference  in  the 
message  tc  the  objea  he  uishes  to  share.  It  is  up  to  the  receiving  end  to  dereference  the 
objea  by  explicitly  asking  for  ii  if  decrr»ed  useful.  The  question  is  once  the  objea  is 
mailed,  who  15  responsible  for  maintaining  consistency  of  the  different  objea  copies. 
Seoion  4.3  gives  a  clearer  account  of  this  method. 

2.1.1  Advantages  or  Approach 

T7)e  advantages  of  the  message-based  approach  are  the  following: 

•  Fits  well  with  distributed  culture 
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Fo:  sys-^m?  C-.i:  are  ee2_-ec  -.ruardv  na:%e  users  a-nc  L-a:  make  extensr.e  use  of  messages  to 
share  L"jrrma:.or..  u?L-g  m.esiages  :c  sr.are  objects  seem.s  tc  be  a  narura^  evoiuuon. 
Moreover.  na:\  e  users  may  fee'  more  comfonible  wuh  explicit  (exposed  shanng  of  objects 
•L-har.  V.VJ:  c-ar. sparer,:  snaTiT.t 

2.1.2  Disadvantages  of  Approach 

The  disadvar.tages  of  the  messagr-based  approach  are  the  following: 
•  Lirr^ted  tc  L^jna-.i-.g  object  shanng 

Limited  'c  :r.::iar.ri  ^ ~  ec'  shs'':r£ 

Tnis  approach  rr.^irl)  focuses  or.  Liitiating  object  shanng.  i.e.,  making  an  objea  accessible 
to  omers  1:  does  nc:  address  the  maintenance  of  the  shared  objea.  Once  there  are  several 
copies  cf  ihe  oDjec;  a;  CLfr'eren:  sites,  the  problem  arises  of  maintaining  and  updatr.g  these 
objects    Tr^^  evol'-es  l-.::  me  i?— hutec  approach  to  object  sharing 

2.2  Centralized  Object  Sharing 

This  approach  dictates  tha:  2II  utformauon  (objects)  deemed  sharabie.  (i.e..  accessible  by 
more  than  I  person  has  access  to  the  objects")  m.us:  be  located  at  a  central  dedicated  site  in 
the  network.  The  overall  conng^jration  is  depicted  in  Figure  2-1. 

This  coriiguranon  falls  into  Lhe  Server-Client  Model,  where  the  central  site  acts  as  a  server 
of  shared  objects  and  the  other  v.orkstaaons  in  the  nerworic  aa  as  clients  requesting  objects 
from  the  server.  Users  will  remotely  access  objects  at  the  central  site  from  their 
workstation.  The  system,  hides  the  details  of  the  remote  access  which  is  slower  than  local 
accesses.  Indicaung  that  an  access  is  remote  may  be  useful  to  explain  to  the  user  ai  the 
client  the  reason  for  the  delay.  With  the  mcreased  speed  of  local  area  networks  the  delay 
would  prol  ably  be  due  to  processL^g  a:  end  sites. 
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Figure2-1:   Cenoaiizcd  Object  Server 


2^.1  Advantages  of  Approach 

Tne  advantages  of  the  cenc-alized  approach  are; 

•  Simple  concuirencv'  control. 

•  No  overhead  due  to  update  propaganor.. 

•  SLTiple  Riile  Rcsoluuon 

Simple  concurrence  convol 

All  accesses  to  shartd  objeCTs  must  go  through  the  cenc'al  server.  It  would  be  easy  for  the 
centra!  ser\er  to  control  and  coordinate  concurrent  access  to  the  same  object.  T^e  choice  of 
a  mechanism  vanes  from  locking  (checkout,  chcckin).  timestampL-.g  .  optLTustic  control  or 
version  merging.  Chapter  3  and  Chapter  4  discuss  the  various  mechanisms  in  a  great 
amount  of  detail.  Of  interest  in  this  approach  are  the  mechanisms  thai  pertain  to  a  single 
copy  of  the  objea. 

No  update  propanahon  overhead 

All  upxiaies  are  directed  to  the  central  server.  Only  a  single  accessible  copy  of  a  shared 
objea  exists  and  is  always  obtained  from  the  central  site.  Hence,  any  ujxiaied  propagation 
overhead  encountered  in  the  distributed  or  cached  approach  is  completely  avoided. 
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Sinr.e  Rule  Rcs'lur-^r 


Simple  quenes  ca.-.  be  lorrr.ulatei  l-.  kt.ou  ledge -based  sysierr.s  usir.g  IF-THEN  rjles.  Tne 
csr~L  approach  aI'.cv->  -j-.e  r„:e5  p^r.zjj-.-jr.z  ic  shared  objects  tc  be  resolved  a:  the  cenraJ 
silt  b\  lookiTiC  ror  objerti  '>r.a:  maicr.  and  perfonr.  the  appropriate  manipuianon. 

2.2.2  Disadvantages  of  Approach 

TTie  disadvaniaces  cf  the  cenralized  approach  are  the  following: 

•  Contention  a:  Cenn-a!  Site 

•  AvailabiliiN  c:  Cenral  S;:e 

•  Rerr.cis  access  a:  eNer.  snared  ocjtct  acces. 

Cortenrion  or  Cc.r-c'  S:u 

The  central  site  needs  to  process  object  requests  from  all  workstanons  in  the  network.  This 

may  lead  tc  a  significar.:  decradatior  ir.  perfom^^ance  The  server  should  be  able  to 
dsyTicbj-onously  accept  object  requests  and  pass  ±ie  object  ids  to  the  disk  manager  for 
rerieval    Once  the  objer.  is  available  it  would  be  returned  to  the  requester  client. 

Ayai!ab:l:r\  o'^Cerr-g!  S:re 

Tne  entire  systerr. 's  access  ;c  shared  objects  is  dependent  on  uhe  availabilirv  of  one  central 
site.  In  case  of  cental  s:te  failure,  users  at  various  worl^^tanor^  will  be  unable  to  access 
ar.y  shared  objects.  Tms  is  not  a  very  desirable  feature. 

Remote  access  or  fvf\  shaded  obec:  access 

Even-  time  a  shared  object  is  accessed  a:  any  workstaaon  this  results  in  a  request  being  sent 
to  the  central  server  demanding  the  object.  Delays  are  unacceptable  when  the  shared  object 
accessed  has  not  be«n  modified  since  the  last  access. 


2.2.3  Improved  Performance  usmg  Cachmg 

This  problem  of  unnecessars  successive  remote  accesses  to  'j-.e  same  object  may  be  solved 
by  desicr.atir.g  ar.  area  lt  memory-  a:  ine  individuaJ  \>.orkstanons  to  cache  remotely  remevsd 
objec.5.  As  long  as  Lhe  objea  has  not  been  modified  by  other  users,  us  state  m  the  cache  is 
Lhe  valid  siaic.  Future  accesses  to  the  object  will  be  directed  to  the  local  cached  copy.  A 
wnte  would  be  done  to  the  cached  copy  and  'iien  w-nnen  through  to  the  ser%er.  Rules  and 
methods  may  be  {jcrformed  locally  on  the  cached  copy. 

G'-aru'ia'-ir.  o'Csrre 

One  issue  is  at  what  granulanry  is  caching  performed.  One  simple  opaon  is  perform 
caching  at  '^"le  level  of  an  object.  Hence,  objects  are  the  unit  of  transfer  benAeen  the  central 
server  and  the  cache.  Tne  other  opuon  is  to  pierform  caching  of  larger  units  such  as 
segments  tcolleaion  of  objec:s,.  A  basic  noaon  in  object-onentcd  s> stems  is  that  related 
objects  that  would  be  accessed  together  should  be  clustered  together.  If  the  segment 
contained  such  a  cluster  of  objects,  then  this  approach  could  lead  to  improved  performance 
because  of  a  decrease  in  the  number  of  remote  accesses  performed,  because  successive 
objea  references  are  to  objects  in  the  same  segment. 

VaLdation  of  Cache 

Moreover,  the  system  should  guarantee  thai  a  user  will  always  access  the  latest  copy.  The 
system  should  propagate  the  changes  made  to  an  object  to  ail  the  copies  of  the  objea  that 
are  cached  ai  woricstanons.  There  are  number  of  ways  for  propagating  the  updates: 

1 .  The  server  maintains  a  list  of  the  objects  thai  arc  cached  ai  each  workstanon. 
If  an  update  is  received,  the  list  is  checked  and  the  appropriaie  workstations 
are  notified  of  the  update.  The  client  may  automatically  fetch  the  updated 
objea  or  prompt  the  user  to  do  so.  A  cleaner  implementation  would  be  to  set 


tr.erer-  i:  checked  cj;  cbjecis  a;  the  ser%er  thai  wUi  automatical]},  mgce:  ar. 
update  p:oces>  l:  L-^.e  cbiec.  l=.  updated. 

2. 1:'  ar.  ob;ec:  is  upda'.ed.  ir.e  ser\e:  sends  messages  tc  me  caches  that  hold  a 
cop>  of  the  obiec:  nva^ica--ir.g  the  stale  of  the  object.  The  cbent  anempts  to 
access  the  cbier.  frorr.  ir.t  cache  L:  the  objcc:  is  valid  it  is  reramed  otherwise 
It  IS  refetched  from  ihe  scr%'er. 

3.  Timesiamp?  are  maintaLned  for  objects  at  the  central  server  At  each  access. 
the  times'.amr  of  the  obiec;  is  retnev&d  from  the  server  and  compared  to  the 
loca^  timestamp  If  differer.:.  the  object  is  retrieved.  Tnis  is  faster  thar. 
retnevL-g  the  objec:  as  a  whole.  Tms  requires  the  maintenance  of  a  larger 
number  of  tme  stamps  than  previous  method.  Method  2  required  nme stamps 
for  seements  and  used  cbects  ir.  the  cache.  This  method  requires  timestamps 
for  all  orjecL-  a*  the  ser\er  zr.d  ir.  the  cache. 

Repiacernen:  of  cached  unirs 

Tne  size  of  the  cache  is  mucr.  smaller  thar.  the  size  of  memor>-  a:  the  object  server. 
Reneved  objer.s  car.  no:  be  cached  mdefinitely.  The  cache  s  Lrnited  memory-  space  needs 
to  be  managed    .Ar.  object  replacement  straiegv  is  required.  The  options  are: 

1.  LRU  Geast  reccnt]\  used  may  be  used  to  select  infrequently  accessed  objects 
from  the  cache. 

2.  FIFO  (first-in-first-out)  may  be  used  to  selea  the  oldest  object  in  the  cache. 

3.  Random,  may  be  used  to  sciea  the  object  to  be  replaced  at  randomly. 

The  server  needs  to  'oe  informed  of  the  cache's  flushed  enincs  so  thai  it  updates  its  list  of 


ob'ccts  and  the  coiTespondL''.c  caches     If  objects  art  cached  our  system  v-U!  have  rr.an>  of 
the  compiexKies  associated  v>.il-.  a  d:snbuted  object  ser\e:  v.  ith  object  replicatior..   Upcate 
rropaearion  is  one  such  complexirv-.    Concurrency  control  will  also  be  more  complicated 
These  are  discussed  bclou  ir.  me  context  of  distributed  objea  servers. 

2^.4  Implemenuucn  of  Central  Data  Server 

The  next  imponant  question  is  the  actual  implemenuiion  of  the  central  scr^'er.  There  are 
two  main  options:  a  central  relational  database  server  and  a  central  objea  sen-'er. 

2^.4.1  Central  Database  Sever 

A  database  server  build  on  top  o'^  a  convennor.al  reiauonal  daiaoase  may  be  used  to 
implement  a  central  data  server.  Shared  object  instances  would  be  stored  in  terms  of 
relations.  Converting  complex  objects  into  a  relation  is  not  always  a  one  step  task. 
Difficulnes  anse  because  of  the  network  strucrure  of  tne  object  space  (objects  u:th  links  to 
other  objects).  Put  in  relational  database  terminology,  it  is  difficult  to  normalize  ±e  object 
network.  A  given  object  will  need  to  be  represented  by  a  number  of  rclauons  to  ensure 
atomicity  of  domains  and  ensure  mutual  independencies  between  different  aimbutes. 
Moreover,  converting  to  normal  form  makes  objea  (clustering  related  objects  together  for 
fast  access)  more  difficult.  Another  difficulty  anses  in  mapping  semi-sructured  objeas 
into  relauons.  The  contents  of  a  field  of  a  Lens  Objea  could  be  a  combination  of  text  and 
links.  This  again  is  not  easy  to  map  into  a  relarion.  Mapping  hypencxt-Uke  objects  into 
relations  wiih  pointers  to  flat  files  again  diminishes  the  power  of  hypertext.  Most  reiauonal 
database  systems  do  not  provide  the  trigger  fcarure  (R*  is  an  exception^).  This  again  is 
another  important  feature  in  the  systems  we  are  concerned  wiih.  Moreover,  since  objects 
are  stored  as  relanons  ai  the  server  methods  can  not  be  performed  at  the  server.  Methods 
can  only  be  performed  at  the  client  side  where  objects  are  formed. 
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Tne  advan:age>  ci  usir.r  a  da-.aba^t  ser. s:  i$  iha:  :t  i5  easiJ\  obLainabie  from  the  markei.  li 
provides  the  techr.olor>  lor  :2^^;  data  access  ar.c  concurrent)  connrol  (aiihouzh  thus  rrugh: 
no:  be  adequate 

Tne  database  ser%er  must  be  abie  :o  asvTichronousJy  accept  requests  from  vanous 
uorkstaijons  l"  the  nerv.o:k-  Tnese  requests  may  be  in  the  fomi  of  a  set  of  relanonal 
queries  tha:  resiJ;  ir.  the  retrieval  of  the  appropnaie  relauons  thai  correspond  to  the 
requested  object,  I:  is  ine  d_"_  of  the  cuent  end  to  translate  object  requests  into  the 
apprcpnate  set  of  reiational  qjenes.  Notice  tha:  this  requires  a  tremendous  amount  of 
processing  a:  Dotr.  sues  Tne  client  end  should  also  extraa  the  necessan'  informauon  from 
the  reruTned  njpies  to  build  up  the  requested  objea. 

Tne  commun:  cation  betv.eer.  the  serv'er  and  the  client  will  be  in  frmi  of  relational  quenes 
and  rerumec  ruple:  Tnt  systerr.  uiT  re;>-  on  the  rclanonal  database  for  transacuon 
management,  concurrency  control,  authonzarion  and  recover)'. 

22.42  Central  Object  Sever 

A  cenrai  object  server  ma)  be  used  to  implement  the  central  data  server.  An  object  server 
returns  objects  Lhat  are  m  the  format  of  objects  in  obje  a -oriented  systems.  (Recall  that  the 
database  serve:  remms  tuples  that  need  to^bc  laier  decomposed  at  the  client  side  to  form  the 
objea).  Messages  bcrvteen  the  client  and  the  server  would  be  in  the  form  of  objea  requests 
similar  to  those  tha:  access  local  objects.  Unique  Objea  IDs  or  objea  queries  (eg., 
description  or  selection  rules)  uill  be  used  to  access  objects  at  the  central  objea  server. 
Tne  central  object  server  will  be  built  on  top  of  a  storage  manager.  The  storage  manager 
could  either  be  an  extended  relational  storage  system  or  a  persistent  objea  store.  The 
relationship  between  an  object  server  and  objects  is  analogous  to  the  relationship  between  a 
filescrver  and  files. 


The  first  approach  requires  extending  a  relational  storage  system  to  accommodate: 

•  the    d;ifferen:    concurrency    concol    requirements    Lha:    result    from,    the    long 
transacaons  character^uc  of  objcct-onented  hNperxext  appucauons. 

•  vcrsior.  maintenance  and  concrol. 

•  efficiendy   mappmg   complex   h\-p)cnex!    and   semis tructured   objects    into   a 
rclaiionai  storage  system-. 

•  tnggermg  of  processes  upwn  the  modi^cauon  of  stored  objects. 

The  second  approach  requires  building  or  acquiring  a  persistent  objea  store. 

•  Tne  obiec:  store  accepts  unique  cDjec:  ids  or  object  quenes  and  rerums  the 
corresponding  objects. 

•  concurrency  conixol  can  be  customized  for  the  Objea  Lens  environment. 

•  version  m.aintenance  and  control. 

•  version  merging. 

•  recovery  and  resiliency. 

•  protection  and  authorization. 

•  triggers. 

The  advanuges  of  the  first  approach  is  that  a  rsiaaonal  storage  system  may  be  acquired  in 
the  market  place.  Feamres  of  fast  access,  protection  and  recovery-  are  already  provided. 
The  advantages  of  the  second  approach  is  thai  the  objea  store  would  be  tailored  to  best  suit 
the  applicauons  of  interest.  The  disadvanuge  is  the  effon  needed  to  build  such  an  object 
store. 

23  Distributed  Object  Sharing 

This  approach  proposes  that  shared  objects  be  distributed  at  various  sues  in  the  nerAork. 

Objects  may  be  dismbuted  in  a  manner  such  thai: 

1 .  one  copy  of  the  objea  is  present. 

2.  mulnple  copies  of  the  object  are  present  (objects  arc  rcplicaicd). 

3.  a  copy  of  the  objea  is  rcplicaicd  at  each  site  (fully  redundant). 


-26- 
Repbcanon  leads  to  ar.  L-T.provemen:  ir,  avajJabilir.-  and  throughput.  It  also  is  expensi%e 
because  it  requires  ,  I  uTcreased  memor>'  space  to  hold  replicated  objects  and.  (2) 
Licreased  overhead  to  ensure  that  updates  go  to  all  copies  of  an  objea  and  that  all  copies 
are  consistent.  Moreover,  traditional  concurrency  control  schemes  lead  to  an  overall 
deterioration  in  performance  u*'  replication  is  performed  at  more  than  4  sues. 

In  the  case  of  no  rephcanon,  ob'ects  may  be  allowed  to  rmgraic  from  one  sue  to  another. 

This  means  Lhai  object  manipulation  m.ay  be  performed  locally. 

2J.1  Advantages  of  Approach 

The  advantages  of  the  distributed  approach  are: 

•  Increased  availabilirv'  of  shared  cata. 

•  Lmproved  access  p>erformance. 

•  Lessened  contenuon  at  storage  sue 

AvaHab'.'.ir. 

In  a  distributed  system  access  to  shared  data  is  no  longer  dependent  on  the  availability  of 
one  site,  since  the  data  is  distributed  over  a  number  of  sites.  Moreover,  replication  of  data 
at  vanous  sites  udl  make  data  access  msensiuve  to  the  failure  of  a  paruculax  site. 

Improved  access 

Replication  will  allow  objea  access  to  be  directed  to  the  closest  site  that  contains  a  copy  of 
the  objea.  V»'nat  site  thiis  is  depends  on  the  implementaiion.  (See  Section  2.3.3). 

Lessened  coniennon  qi  single  srorgge  site 

In  the  distributed  case,  object  requests  go  to  one  of  a  number  of  objea  servers.  This  leads 
to  an  improvement  in  performance  because  objea  access  is  no  longer  restricted  to  a  single 
machine. 


2  J. 2  Disad\anta^es  of  Approach 

Tne  d:sadvar.:ace>  rf  Lnt  cLsr-.^uted  aprroach  are: 

•  mere  corr.piex  concurrenrx  control. 

•  upda:;  propiCa:.?r.  c^ernead 

•  complex  rule  resolunor.. 

•  complex  recoverN . 

Complex  Concun-enr\  Corp-:'! 

Ailovkuic  object  rephcanon  complicaies  concurrency  control  because  concurrcn:  accesscrs 
at  different  sites  are  harder  to  detect  than  concurrent  acccsscrs  ai  one  sue.  Each  user  is  able 
to  access  the  closes:  ccr;-  of  ar,  object  and  perforrr.  his  changes.  The  system  should  be  able 
to  detect  such  confiiris  and  provide  a  mechanism  for  resolving  them.  Chapter  3  section  3 
preser.:>  a  detailed  s'ur>e>  of  su;h  detection  and  resolution  mechanisms  and  Chapter  6 
sccuon  A  presents  mechanisms  appropriate  for  Distributed  Object  Lens. 

Updaic  Prnpa£a:ior 

AlloNMng  replication  introduces  the  problem  of  maintaining  consistency  between  the 
various  copies  of  an  object  at  the  various  sues.  For  traditional  database  systems  a  user  must 
be  guaranteed  tnat  he  b  reading  tne  latest  committed  cop>  of  an  objea.  We  will  see  later 
that  thus  requirement  ma>  be  relaxed  in  an  cnvironmem  such  as  Object  Lens.  In  some  cases 
it  is  suffiaent  to  pve  a  user  access  to  the  lattst  local  copy  with  an  indication  thai  it  might 
not  be  the  latest  copy  in  the  distributed  system.  Chapter  3  section  2  presents  a  detailed 
account  of  the  various  update  propagation  strategies  and  Chapter  6  section  5  describes  how 
jjropagarion  of  updates  may  be  performed  in  Distributed  Objea  Lens. 

Complex  Recovery 

Rccoverv-  and  reliabilin-  are  much  more  complicated  in  a  distributed  system.  Network 
partitions  may  result  in  inconsistencies  between  various  copies  ai  various  sites. 
Inconsistencies  mav  be  detected  but  are  verv  hard  to  resolve. 
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Complex  Rule  Resolution 

Since  objeas  are  dismbutfrd  over  a  number  of  sues,  this  requires  thai  a  rule  be  applied  at 
the  sues  v.  here  the  objects  in  question  are  stored  m  order  to  search  for  objeas  that  match 
the  rule.  There  are  three  possible  ways  to  handle  this: 

l.Subrules.  The  collection  of  objects  being  considered  may  be  virrually 
divided  mco  subcoUecuons  indicating  their  location  site.  A  message  is  then 
sent  to  each  of  the  appropnate  sue  containing  the  rule  and  the  considered 
objects.  The  rules  fire  at  each  of  the  storage  sites  and  the  results  are  directed 
back  :o  the  initiating  sue.  This  is  analogous  at  a  simple:  level  to  query 
execution  m  distributed  relational  databases. 

2.  Migration.  The  required  objects  may  migrate  to  the  site  of  execuaon  of  the 
rule.  The  rule  is  then  fired  and  the  appropriate  results  returned.  The  rmgrated 
objeas  could  be  returned  to  their  onginaJ  site  then  or  a:  a  future  time  when 
the\  are  requested. 

3.  Replication.  In  the  fully  redundant  case,  all  objects  accessed  by  a  user  are 
already  present  at  his  objea  sers-er.  This  means  that  any  fiXed  rule  docs  not 
need  to  access  an  remote  objeas.  This  of  course  requires  an  increase  m  the 
amount  of  memory  space  needed  and  an  increase  m  the  overhead  inairred 
because  of  update  propagarion  and  complex  concurrency  control. 

2JJ  Implementation  of  a  Distributed  Data  Server 

There  are  three  main  approaches  to  distributing  shared  objects  over  sites  in  a  distributed 
environment.  TTie  sites  may  be  dedicated  objea  servers  or  extended  super  workstations  that 
can  store  local  as  well  as  commonly  used  shared  objects.  The  object-oritcnted  hypertext 
system  may  also  be  implemented  on  top  of  a  distributed  database  system.  We  will  address 
the  requirements  and  implications  of  each  of  these  approaches  in  turn. 
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2-?. 3.1  Distributed  Object  Server 

Thii-  approacr.  irr.z'.isb  n:  ex:sier.ce  of  several  object  se-. ers  ui  me  ner^oiK  and  migh;  or 
m!Eh:  no*,  supper.  repl::a:ion  of  daia    Tnc  aciua]  confifurauor.  of  the  ncrvork  is  depicted  ir. 


.'.   tz:  rerejf 
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Figure  2-2:   E>istribuie<i  Object  Scr\'er 

In  terms  of  me  chen:-ser.er  model,  there  are  a  number  of  dcdicaied  servers  in  the  system. 
A  client  serMce  is-  implemented  a:  each  uorksta'jon  to  direct  object  requests  tc  the  relevant 
server.  We  w  iL  refer  to  the  chen;  as  the  object  manager. 

Tnc  different  object  ser%ers  collaborate  to  provide  a  system-wide  shared  object  space.  Such 
a  system,  should  provide  location  transparency.  In  other  words,  the  user  is  not  exposed  to 
the  location  of  the  object.  Tne  system,  should  also  provide  rcplicanon  transparency. 
Objects  may  be  replicated  a:  various  objea  servers  for  increased  performance.  Object 
managers  arc  located  ai  each  workstation  to  direa  and  control  object  access  to  the 
^Tpropriatc  objea  server. 

Duties  of  Object  Manager 

The  duucs  of  the  object  manager  can  be  summarized  as  follows; 

•  Locanng  the  requested  objea. 

•  Rule  or  method  execution. 

•  Managing  a  cache. 
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Locanon  of  ob'eci 

Tnc  object  maDag;:  needs  to  locate  v-hers  the  requested  object  is  stored  This  may  be 
performed  ir.  several  'j-ays.  One  scheme  would  be  to  use  a  r.ame  se^^■e:  that  g:ven  an  object 
unique  id,  rerums  'j\e  object's  location  and  ir.temal  id.  The  request  is  then  directed  to  the 
appropnatc  object  ser-er  Tne  name  ser--er  could  eiLhe:  be  centralized  or  repiicaied  at  each 
site  in  the  nerwork. 

An  alternative  scheme  v^ould  be  for  objects  tc  have  unique  system-wide  object  ids  that 
reflect  iheL-  locat-.or.  Tr^s  allows  object  managers  at  the  different  workstar:ns  to  extract 
the  name  of  uie  appropnate  object  server  w  here  the  object  is  located. 

If  objects  are  allowed  to  migrate.  Lhen  Lhe  second  approach  would  not  make  sense.  The 
name  serve:  approach  could  be  used  tc  morjtor  i-.e  change  m  locanons  c:  objects.  Ever> 
time  an  object  mugraies  its  enr>-  in  Lhe  name  server  is  updated.  If  the  name  server  is 
replicated  at  each  client  site,  the  change  in  locauon  has  to  be  propagated  to  all  sues. 
Another  possible  opt:on  is  for  an  object  to  leave  a  forwarding  address  indicating  its  new 
location.  This  'oecomes  slow  if  objects  migrate  a  lot  (since  several  forwarding  addresses 
need  to  be  followed  before  the  object  is  locaiedj. 

Rule  or  method  execution 

Rules  and  methods  need  to  be  executed  ai  the  objects  storage  site.  It  is  the  responsibility  of 
the  object  manager  to  direa  the  rule  execution  to  the  appropnate  sites  (as  explained  earlier). 

Managing  a  cache 

If  caching  is  going  to  be  used  then  the  objea  manager's  responsibiIit>'  is  to  manage  the 
cache.  We  mentioned  in  section  2.2.3  the  unplicauons  of  caching. 
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Duties  of  Obiec:  Server 

Thf  duties  of  the  object  ser\er  car.  x  sainmanzed  as  foIio>AS 

•  Accep:  objec:  rsques:s  o:  queries  and  rerum  objects, 

•  Protection  and  Au'jionza'jor.  of  objects. 

•  Version  Conrol 

•  Recover 

•  Clusiennc 

•  Tngce:> 

•  Update  Propagarion 

•  Concurrenc}  Conro! 

Accer:  cbier:  reaue^^:^  or  auer.es 

The  object  se:^  e:  processes  the  uruque  objea  id  and  renims  the  requested  object.  It  should 
also  be  able  to  accept  a  quer%  indicating  specific  attributes  of  an  objea  and  return  the  set  of 
objects  tha:  match    Ir.dexir.z  sc.z  other  feauires  need  to  be  used  to  improve  access  time. 

Protect! en  and  Author.t:a::?r  of  O'necis 

Tne  object  manage:  is  responsible  for  mamtaining  concroDed  access  tc  shared  objects. 
Given  an.  object  access  request  and  the  user's  id  the  objea  manager  verifies  that  the  user  is 
authonzed  to  access  the  object  in  the  specified  mode.  Protection  may  be  performed  using  a 
capabiiirv -based  mechanism  or  access  control  lists.  Sec  Section  3.4  and  Section  6.3  for 
further  details. 

Version  Control 

The  objea  manage:  is  responsible  for  maintaining  different  versions  of  the  objea  and 
alerting  the  user  to  the  existence  of  the  different  versions. 

Recovery 

The  object  sever  is  responsible  for  ensuring  the  persistence  of  the  objeas.  It  should  have  a 
sound  recover\  scheme  u^  case  of  sue  failures. 


Clustgnng 

If  segments  are  used  as  the  'jrut  of  transfer  berv-esr.  ihe  ser-c:  and  the  client  cache  fir,  case 
of  cachx.g),  then  Lhe  object  ser.er  is  responsible  for  clustering  related  objects  together  mto 
segments  stored  ai  the  server. 

Tnggers 

The  objea  server  should  be  able  to  send  trigger  messages  to  the  objea  manager  if  objects 
have  been  updated  or  if  links  have  been  added. 

Concurrencv  Conrc'.  and  Update  Prcraeatior 

It  is  difficult  to  classif>-  at  uhat  end  (object  server  or  objea  manager)  each  of  these 
important  funcuonaliues  fall.  It  is  highly  dependent  on  the  concuirencN-  and  propagation 
schemes  adopted.  Implementation  notes  are  made  in  Chapter  6  regarding  each  of  the 
schemes  in  the  context  of  Object  Lens. 

2JJ2  Object  Server  and  .Manager  at  each  Workstation 

This  ^rproach  is  an  extension  of  the  distributed  object  server  approach.  Objects  are 
distributed  over  the  memor,-  space  of  the  workstations.  Each  worksution  is  extended  to 
have  its  local  objea  manager  and  an  object  ser\er  talrcady  present).  Object  servers  aie  no 
longer  dedicated  machines  but  implemented  at  each  workstarion.  Each  objea  server  is 
responsible  for  local  objeas  that  could  be  shared  or  personal.  Objea  managers  are  only 
responsible  for  protecting  objects  at  its  site.  Objea  access  is  directed  first  to  the  local 
manager,  which  in  rum  directs  a  to  the  appropriate  objea  manager  if  the  object  is  not  local. 
Communication  occurs  between  objea  managers  as  opposed  to  between  object  manager 
and  objea  server  as  in  the  earlier  approach  to  access  an  objea.  Otherwise,  the  dudes  of  the 
objea  manager  and  the  objea  server  are  more  or  less  the  same  as  in  the  distnbuted  object 
server  approach. 
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Figure  2-3:  Obiec:  Serve:  and  Manager  at  each  Workstanon 

2333  Distributed  Relational  Database  Systems 

This  approach  suggests  ma:  Distributed  Object  Lens  be  build  on  top  of  a  distribuwd 
relational  database  Trus  agair.  ma%  be  acquired  in  the  market  place.  The  distributed 
relational  database  is  able  tc  provide  the  data  management  features  and  an  intermediate 
mterface  needs  tc  build  tc  provide  the  charactensucs  of  an  object -onented  system.  The 
distributed  relational  database  provides  the  locatjon  and  replication  transparency.  It  will 
also  provide  the  concurrency  connol.  update  propagation,  secunty  and  authonzanon.  The 
difficulr\-  anscs  as  ui  the  case  of  a  cenral-iZed  relational  database  in  mapping  object- 
onented  objec:  space  into  a  relational  strucrurie.  More  over,  the  concurrency  control 
mechanisms  r\7:c2ll>  provided  by  distributed  databases  are  not  adequate  for  applications 
supported  by  objea-onented  database  systems  or  hv-penext  systems. 


To  summarize,  here  arc  the  p>ossiblc  configurarions  for  sharing  objects  in  a  distributed 

environment  in  the  framework  of  a  server-client  model. 

1 .  One  shared  object  server  /  object  manager  clients  ai  workstations. 

a  Caching 
b  No  caching 

2.  A  number  of  dedicated  objea  servers  /  objeCT  manager  clients  at  workstations. 

a  Replication 

i  Caching 

ii  No  caching 
b  No  rephcauon 
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Figure  2-4:  Disnibui&d  Reianonal  Database 

i  Caching 
ii  No  cachmg 

3.  Objec:  ser/er  and  object  manage:  clien:  a:  each  workstation 
a  Rephcaiion 
b  No  rephcauon 
i  Nligrauon 
ii  No  migrauon 

The  other  dimension  c:  thjs  is  how.  the  object  scr\-er  is  mpiemented.  Tne  :\<.c  opaons  are: 
on  top  of  a  relational  storage  systrrr.  or  on  top  of  an  objer.-oriemed  storage  system.  The 
requirements  of  each  v-ere  outlined. 

The  difference  between  a  single  object  ser\'er  with  caching  and  the  disuibuted  approach  is 
d:at  of  concurrency  control.  Both  require  update  propagation  techniques.  Tne  former 
requires  a  simple  concurrency  control  since  conflicts  may  be  deiecxed  at  the  ccnrral  site. 
Conflicts  are  harder  to  dctea  in  the  later  case,  since  they  need  to  be  detected  across  server 
sites. 
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Chapter  3 
Object  Sharing  Features  in  a  Distributed  Environment 

In  Char:e:  2.  ue  rresenied  rv.o  rr.air.  approaches  to  object  shanr.g.  cer-rdlized  ar.d 
dismbuted.  Ar.  s.-.szzil  par.  of  boir,  approaches  is  concurrcricy  control  and  update 
propagation     Update  propagation  is  on]>  necessan  if  more  than  one  cop>  of  an  object 

CXlS'^. 

In  this  chapter  v.e  ar.empt  to  st:r\e\   different  aJgorithms  and  schemes  proposed  to  the 

foliowing  fearjres  required  it.  a  distributed  system  to  provide  object  sharing  capabilr^-ies. 

•  Replication  and  Update  Propagation 

•  Concurrenc>  Control 

We  also  look  a:  var.ous  protection  schemes  that  p. -vide  differing  access  rights  tc  sharers  of 
a  shared  object 

3.1  Replication 

Data  replication  means  that  a  given  logical  daia  can  have  several  dis'jnct  stored 
representatives  at  several  sites    The  advantages  of  such  an  arrangement  arc: 

•  Reduced  commurjcaiion  traffic  and  improved  response  tame  by  providmg  local 
representanves. 

•  Accesses  to  the  same  logical  data  by  several  users  may  be  serviced  in  parallel, 
improving  system,  throughput. 

•  Increased  system  availabUiry  by  allowing  a  given  data  object  to  be  available  for 
processing  as  long  as  at  least  one  replica  is  available. 
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SupportLng  r:-p'.:zai  hcAe'-er.  corriplica'.ss  ih:  deiails  of  data  rerieval  and  TiodLfica::cr. 

3.2  ConsistencN  and  Update  Propagation 

.A-".  update  to  a.-:>  e:'-fr.  logical  da:a  object  rr/jst  be  propagated  to  ail  stored  rcprcsentanves 
of  's.s  ob'er..  Consistency  of  th.e  representatives  n-.-js:  be  ens'jred.  Tv-o  degrees  of 
consistency  are  possibie: 

•  Perfect  consistency  L-nplies  thai  all  representatives  ::  L-.e  diia  cb;ec:  have  the 
same  initial  '•alues  and  ^nsr  sacr.  -" .'. ~ • '~ ~ ?.'  r-—.  ?.  .  the  r^t^resentatr-ss  are 
Lnstantly  upcatec  l-  i-.e  ia.—.:  •*a>  to  remain  identical  throughout  cim.e  This  is 
difnciil:  to  ensjre  because  scm.e  sites  contariing  the  repre>er.:arves  ma\  be 
una\a:Iab".e  a:  the  time  of  updais 

•  Lcoser  fom^.s  of  consistercy  im.pA  i-.at  all  representatives  v-iH  evenmally  be 
updated,  so  tha:  the  representatives  converge  to  tr.e  same  value  a:  some  tme 
Lnter%  al  after  updates  have  stopped. 

Update  Propagation  is  a  problem,  even  -s.  a  singie-uscr  disthbuted  system.,  uhere 
concurrencv'  control  consideratior^s  uhat  anse  m  a  muln-uscr  system  may  be  ignored.  There 
arc  trj-ee  basic  me'^hods  for  pcrformang  update  propagauon: 

1.  Pnraar.-  Ccpv  Update.  One  representanve  of  the  data  object  is  designated  as 
the  prjT.ary  copy.  Ail  vi,-ntes  done  to  the  data  object  must  be  directed  to  Lhe 
pnm.ary  copy.  A  vtnte  is  complete  as  soon  as  it  has  been  applied  to  the 
phmary  copy.  It  is  then  the  primary  copy's  site's  responsibility  to  proragaie 
the  update  to  ail  oLher  sues  that  have  reprcscntahves  of  the  data  objea.  Reads 
may  be  directed  to  any  representanve  of  the  data  object.  Tnc  disadvanuge  of 


Lh:s  me'jioc  is  i:s  deper.dency  on  the  a\ai^2bLir\  of  the  primary  sue  One 
solution  to  ih:<  is  ihe  ■no\Lnc  pnmar>  site  .  Once  the  pninan  site  is  dov..-..  a 
neu  rrjr.a.-   site  is  ele::?^  (according  to  some  voLing  rule). 

2  Dismbjtec  U?da:e  ^u-nte-aU ..  A  read  operanon  may  be  directed  to  any 
represen:a::\e  of  the  data  object.  A  unte  operation  is  applied  to  all 
represen;a:ues  of  the  data  obje~.  A  u-nte  is  complete  onJ\  when  i:  has  been 
applied  to  ail  representatives.  Tne  difficulty  anscs  when  some  sues  arc 
unavailable  (disconnected.,  i.e.,  a  uTite  would  fail  if  not  all  sites  are  available 
10  approse  w.s  update. 

3.  Ma'?r.r\  Co-.^er-ji,  Acii--^  the  uTite  are  directed  to  ai!  representatives  of  an 
object,  however  orl]~  a  majority  of  sues  need  to  approve  the  update  before  the 

WTue  is  com.~:r.ed. 

[Demers  SS]  alcor/j---r.  allo-»>.'s  for  a  looser  consistency  control.  Background  processes 
cns'ure  tha:  differe-:  replicas  evenrjally  converge.  Hence  reads  may  be  direaed  to  an 
outdated  copy  of  ar.  ob;.s::.  Tnis  migh:  be  acceptable  for  some  applications. 

3.3  CoDCurrenc}  Control 

In  a  multi-user  system,  different  users  may  access  the  same  logical  data  object  concurrently. 
Concurrency  control  preserves  the  illusion  thai  each  user  is  executing  alone  in  a  dedicated 
system.  Concurrency  control  prevents  data  modifications  performed  by  one  user  from 
interfering  with  data  remevals  and  ujxiatcs  performed  by  another.  The  concurrency  control 
problem  is  exacerbated  in  a  distributed  system  because: 

•  Users  may  access  data  stored  in  many  different  computers  in  a  distributed 
svstem. 
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•  Users  rr.a>    concurren-Jy  access  differen:  representai:vcs  of  die  same  logical 
daia  objec!  at  differer.t  sites.     One  sue  cannot  insian'^aneously  knov.   about 
LT.eractior.s  at  oiher  sites. 

Conflicts  that  rr.ay  anse  fall  into  two  caiegones:  version  conHias  and  senaJizable  conilicts 
[Couiouns  88]. 

Version  Conflias 

These  resuit  \».hen  users  access  different  representanves  of  an  object  and  perform 
independent  modificanons  to  different  fields  or  slots  in  the  object.  Such  confnas  may  be 
resolved  using  version  control  and  mereir.g  To  illustrate  the  notion  of  version  confhcts. 
consider  a  fue  accessed  by  rv.o  concurrent  transacuons.  The  first  transacuon  modifies  text 
at  the  top  of  a  f^e  and  the  secor.:  —odjies  te\:  at  the  bortom  of  a  file.  Tne  versions  can  be 
merged  to  mclude  both  changes  Su;h  concurrency  control  schemes  wlC  be  discussed  in 
section  3.3.5. 

Senalizable  Confjcts 

Tnese  cor.f.icts  anse  when  users  access  an  objea  concurrently  and  perform  dependent 
modificauons  to  the  objea.  Here  concurrency  control  is  achieved  ry  adopting  a 
syTichroruzaaon  technique  that  ensures  that  the  outcome  of  p*-o  interleaved  transactions  is 
equivalent  to  execution  of  the  rwo  transactions  in  serial  order  [Bernstein  81].  These 
techniques  prevent  or  detect  conflicts  when  they  occur.  To  illustraxe  the  nouon  of  a 
serializable  conflict,  consider  a  data  objea  x  and  two  transactions  Tj  and  T  .  If  T,  issues  a 
read  and  T.  issues  a  wrue.  the  value  read  by  Tj  will  differ  depending  on  whether  the  read 
precedes  or  follows  the  wnte  (rw  conflict).  Similarly  if  both  transactions  issue  write 
operations,  the  value  of  x  depends  on  which  write  happens  last  (vvw  cor^ict).  Consider  the 
case  w  here  transactions  Tj  performs  x  =  x  +  1  and  transaction  T;  performs  x  =  x  -  1 .   Both 


car.sariior.s  need  '.c  reac  and  wnie  x     If  bo'J:  transactions  are  exeruied  concurrent] % .  the 

the  reads  and  wTites  m2\  l>e  mteriea'.ec  ir.  Lhree  ua\s  as  shovk.T.  ir.  Figure  3-1 

Be;c—  I.                     L.                     I,                    l^                    Acq.!             ijixnoii 

IC                   (1                    T  R!t    IC         W(x    11                                                     10                   10 

T  R  I  ::      ^  ,1   10 

K                f:                "  R'l    "                          W(xj  11                         *                  IC 

T^  R;x    IC                           •»\(it9 

10                 (3                 T  Ru    IC                                               W(x,  1111                  IC 

T  R.J    ;C        V,    X   c            ■ 


Figure  3-1 :  Example  of  Conflicts  in  transactior.s 

Execution  H )  is  the  senalized  execution  of  T,  and  T.  Execution  (2)  illustraies  a  rv.  and  a 
H^-  corJ":ic:  ifT.  and  T,  are  concurrent.  Execuuon  (3)  illustrates  a  rw-  and  a  vi-w  conflict  if 
Tj  and  T  are  con:-rrent. 

^vi  conflicts  ar.d  v^v,  corj~;r:s  car.  lead  tc  anomalies  such  as  a  "lost  update"  or  an 
"inconsistent  read  .  Note  that  v.e  wiL  see  ia;e:  that  senalizabilirv'  might  not  be  required  for 
all  transaction  m  design  and  h\-penexi  systems.  It  is.  however,  of  paramount  imponance  in 
database  s>'stems. 

SvTichronizaiion  techniques  ma>  be  categorized  as  optimistic  or  pessimistic  in  narure. 

"Pessimistic"  assumes  thai  concurrent  transactions  accessing  the  same  object  will  lead  to 
conflict  and  hence  makes  one  transaction  wait  for  another  to  complete  before  it  is  started. 
Synchronization  lechruques  based  on  two-phase  locking  fall  into  this  category.  The 
disadvantage  of  this  approach  is  the  p)ossibility  of  ckadlock.   A  deadlock  arises  when  a  set 

of  transactions  are  waiting  for  each  other  to  comrrut  before  they  can  proceed. 

"OptuTusnc"  takes  the  view  that  concurrent  transacuons  accessing  the  same  objea  may  not 
conflict.   Transacuons  are  allowed  to  proceed  until  a  conflict  is  detected.    S>'nchronization 
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techniques  based  on  timestamp  ordenr.g  and  optun:s:ic  concurrency  control  fall  into  this 
caiegor.        The    disadvantage    of   this    approach    is    the    overhead    incurred    in    redoing 
transactions  once  conflicts  are  detected. 

Tne  rcmairong  of  this  sccnon  is  dedicated  to  examining  the  various  synchronizanon 
techniques  thai  have  been  proposed.  Pan  of  the  classification  is  based  on  l^emstein  81]. 

3.3.1  Synchronization  Techniques  Based  on  Two-Phase  Locking 

Tvi-o-phase  lockL".g  f2PL)  sv-nchronizes  reads  and  writes  by  explicitly  detecting  and 
preventing  conflicts  'DCPAeen  concurrent  operations  Before  reading  data  object  x.  a 
transacnon  must  ov.ti  a  read  lock  on  x.  Before  venting  into  x,  it  must  oun  a  write  lock  on  x. 
The  ouTiersmp  of  locks  is  governed  by  tv-o  rules; 

1.  Different  transactions  cannot  simultaneously  own  conflicting  locks;  two  locks 
conflict  if  both  are  locks  on  tne  same  data  item,  one  is  a  read  lock  and  the 
other  is  a  write  loch,  or  one  is  wnre  lock  ar.d  the  other  is  a  write  lock. 

2.  Once  a  transacuon  surrenders  ownership  of  a  lock,  it  may  never  obtain 
additional  locks. 

The  first  rule  describes  the  first  phase  (lock  acquisiuonj  and  the  second  rule  describes  the 
second  phase  vlock  release). 

3J.1.1  Basic  2PL  Implementation 

One  cop\  ofobiec: 

Associated  with  each  site  is  a  Lock  Manager  (LM)  responsible  for  processing  lock  requests 
and  releases  for  objects  stored  at  that  site.  A  transaction  wishing  to  read  or  write  a  data 
objea  X  requests  the  corresponding  lock  from  the  LM.  If  the  requested  lock  cannot  be 
granted,  the  ojxradon  is  placed  on  a  waiting  queue,  ^lien  a  lock  is  released,  the  operarions 
on  the  waiting  queue  of  the  object  x  are  processed  in  a  first-in/first-out  order. 
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Redundan-  cones  o^  oh  tec: 

TTiis  irr.piemer.tai.o-  v-o:;:^  correc'J)  for  redj-idaTi!  copies  \r.  the  following  wa\  ar. 
opcra::or.  rr,2>  read  ar:>  ccp>  and  need  on^>  ob'-iin  a  re'a<3'  /oi:*.  or.  Lhe  cop\  cf  x  r.  acruallv 
reads.  However.  \i  an  operanon  is  updaung  j:.  then  it  must  update  all  copies  of  x,  and  so 
must  obiam  wrue  loclj,  or.  al!  repressr.:a::ves  of  ;!:.  A  ru  conTuc:  15  detected  at  the  s::e 
where  the  read  lock  is  acquired  and  a  v.-^  confLc:  is  detected  at  all  sites.  This  scheme  is 
vulnerable  to  global  deadlock  during  the  viruf  locks  acquismon  phase  for  the  different 
representatives  of  ar.  ob;ect.  Tv.o  transacnons  T,  and  T  might  be  simultaneous]},  be 
obtaunung  v-.-;.y  locks  on  the  copies  of  x  x^^.  ^2-  A;.  .x_..  a^  If  T,  has  obtained  v,rue  locks  on 
j:j  and  x-.  T  ha.^  obtained  wrue  locks  on  a-.,  x^  and  j:<,.  neither  transacnons  can  proceed  anv 
funher  because  neither  can  obtair,  locks  or  Lhe  remaining  representatives  of  x.  Once  the 
deadlock  is  detected,  one  transaction  is  picked  (perhaps  the  one  with  fewer  locks)  and 
rolled  back.  Tne  follov^i-.g  uiree  locking  schemes  pa)'  more  artenuon  to  red'undant  copies 
and  avoid  such  lock  acquisition  deadlock. 

3-3.1.2  Primary  Copv  :PL 

Redundan:  cones  o-^ ob'er: 

In  this  im.plementatjon,  one  copy  of  the  logical  data  objea  x  is  designated  to  be  the  pnmar\' 
cop\ .  Before  accessing  (.read  or  wnic)  any  copy  of  the  logical  data  object,  the  appropriate 
lock  must  be  obtained  on  Lhe  primary  copy.  For  read  locks  this  technique  requires  more 
communicarion  than  the  basic  2PL  because  the  operation  needs  to  commumcaxe  with  the 
pnTnury  site  in  order  to  obtain  the  lock  as  well  as  the  site  where  the  read  will  occur.  Both 
ru'  and  k-h  conflias  arc  deteaed  at  the  primary  site. 

33.13  Voting  :PL 

Redundan:  copies  of  obiecr 

This  technique  is  only  suitable  for  k-u'  synchronization.    A  transaction  lock  point  occurs 

when  it  has  obtained  a  majonrv  of  write  locks  on  each  data  object  in  its  write  set.    The 


various  lock  managers  acknouiedge  immediately  whether  the  lock  is  set  or  blocked.  If  rwo 
transacnons  cor.currer.tiy  issue  ar.  update.  orl\  or.c  v.-^  a:h;e^e  majonr>'  vote  and  wJI  be 
able  to  proceed. 

3J.1.4  CentraJized  2PL 

Redundan:  copies  o^ ob-ecr 

In  this  techrjcue.  one  cencai'^zcd  lock  manage:  is  present  in  the  system.  Before  accessing 
data  at  any  site  appropnate  locks  must  be  obtained  from  the  central  lock  manager.  Hence 
both  ru  and  h%*  conflicts  are  detected  by  Lhe  lock  manage:. 

3  J. 1.5  Granularity  of  Locking 

Locking  ma>  be  rerfcrmed  a:  iiifere.".:  rrar.ulir.t.es  Se~.er.ts,  obje:*^  cr  object  fields 
may  be  locked  depending  on  the  desired  applicanon  and  concurrency.  Decreasng  -te  lock 
erar.ular.Tv  imrro^es  cor.cu-rrenc\'  7?iis.  ho'^e'-er,  recuir;^  a  iarcer  iock  table  tc  be 
maintained  and  kept  i:pto  date  among  the  various  sites. 

3J.L6  Deadlock  Detection 

The  preceding  implementations  of  2PL  force  transactions  to  wait  for  unavailable  locks.  If 
this  waitmE  IS  unconrolled  a  deadlock  siuiatior.  mav  anse   see  Fieurt  3-2;. 
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re^uea(x) 


Deadlock 


Figure  3-2:  Deadlock  Siruation 

The  basic  characteristic  of  a  deadlock  is  the  existence  of  a  set  of  transactions  such  thai  each 
transaction  is  waiting  for  a  resource  locked  by  another  transaoion  that  is  directly  or 
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indiTcc-J)  wajiL-.c  for  th?  firs;  Thi5  s:rua:ior.  car.  be  convemeniiy  represented  v.iu-,  a  ua::- 
fo:  prarr.  A  w.a::-fo:  craph  15.  a  C-ecied  graph  havuig  cransacuons  as  node;  ar.  edee  from 
transacDor.  Tj  ic  ransartior.  T-  represents  the  fact  Lha:  T|  is  waiting  for  a  resource  iockec 
b>  T^.  The  existence  0:  a  deaiock  siruaiior.  corresponds  to  the  existence  of  a  cycle  in  the 
v.a:t-for  grap".,  Ficj~  ?-3  shows  me  ua:t-for  graph  fo:  the  deadJock  cxamr'.e  in  Figure 
3-2. 


Figure  3-3:   Vvaii-for  Graph 

Two  genera]  techniques  are  a\  c—able  for  deadJock  resolution: 

•  C>ead!:^ct;  Prevenuon.  Tr.ii-  is  a  cautious  scheme  in  which  a  transaaion  is 
aboned  and  restar.ed  v. hen  Lh°  s>stem  detects  thai  deadlock  might  occur.  Tne 
basic  approach  l^  to  assign  pnonues  (possibly  nmesLamps)  to  transactions  and 
to  decide  whether  T^  (requesting  lock)  can  wait  for  T  (alread>  owns  lock).  If 
the  test  faiii.  one  of  Lhe  two  are  aboned  and  restarted.  For  example,  Tj  could 
wait  for  T,  n  T,  has  lower  pnoriry  then  T  This  prevents  deadlocks  because, 
for  ever\-  edge  <Tj,  T  >  m  the  wait-for  graph,  T,  has  lower  priority  then  T  . 
Since  a  cycle  is  a  path  from  a  node  to  itself  and  since  Tj  can  not  have  lower 
priohry  than  itself,  no  cycle  can  exist. 

•  Another  scheme  is  prcordenng  of  resources.  This  is  a  deadlock  avoidance 
technique  that  avoids  restarts  altogether.  This  technique  requires  the 
prcdeclaraiion  of  locks  (each  transaction  obtains  all  its  locks  before  execution). 
Data  items  are  numbered  and  each  transaction  requests  locks  one  at  a  time  in 
numeric  order.  The  prioriry  of  a  transaction  is  the  ntimbcr  of  the  highest  lock  it 


owns.    Slicc  a  rar.sactior.  car.  onJy  u  ii:  for  trar.sa:::or.s  with  hughe:  pr.onr\-. 
no  deadlocks  car.  occjt. 

•  Deader: •■  De:e:'-:or..  L".  •Ji:s  scheme.  cran.sacuoni  wa:t  for  each  other  ir.  ar. 
unconn-oLled  manner  and  are  only  aborted  if  a  deadlock  acruaUy  occurs. 
Deadlocks  are  detected  by  cor.sr-jr.ir.e  wait-for  graphs,  searching  for  cycles 
and  picking  a  transacuon  in  Lhe  cycle  to  abon.  Tnis  is  complicated  in  a 
distributed  environment  because  transacdons  may  be  executing  at  different 
sites.  Moreover,  transactions  may  '5e  divided  into  subransacaons  tha:  ne*d  to 
be  performed  at  sites  where  data  is  stored. 

3.3^  Synchronization  Techniques  Based  on  Timestamp  Ordering 

T'jnestamp  ordering  is  a  technique  whereby  a  ser.alizarion  order  is  selected  a  priori  and 
n^ansaction  execution  is  forced  :o  o'ocy  this  order  Each  ransacuon  nas  a  stamng  time  and 
each  piece  of  data  has  the  timestamp  of  '-".e  transacuon  that  last  read  it  and  the  n^nsaction 
thai  last  wTote  it.  These  techniques  allow  a  n^ansaction  to  read  or  ^ritc  a  data  object  x  only 
if  X  had  las:  been  w.T.r.en  by  an  older  transacuon;  otherwise  it  rejects  the  operation  and 
restar.s  'iie  transaction.  Generating  timestamps  m  a  diszr.buted  system  is  more  complex 
than  in  a  c«nralized  system  because  of  the  lack  of  a  global  clock.  Many  tecrjuques  have 
been  proposes!  to  ensure  the  uniqueness  of  the  dmestamp  [Lampon  7S]. 

3  J.2.1  Basic  Timestamp  Ordering 

One  cop\  ofObiea 

The  basic  dmestamp  mechanism  applies  the  following  rules. 

1  Each  transaction  receives  a  timestamp  TS  when  it  is  initiated  at  tbe  site  of  origin. 

2  For  each  data  objca  x.  the  largest  omesump  of  a  re*d  opennoo  and  the  largest  omesiirap  of  a 
wntc  operanoD  are  recorded  -  indicated  by  RTMa)  and  >^TM(x). 


3  Fo"  readi.  if  TS  <  \^TM  x  i  e  the  Lransacuoc  is  tn-uig  ic  read  da-.a  t^a:  «tas  wntier,  b-  a 
"later'  transa:i:or.  the  rea::  operauor.  l-  reier.e^  and  txie  issuing  tra.isa::ior.  is  resians^  uiil  i 
De«  higher  Dme5ia.T.p.  otbcr^ise  the  read  is  executed  and  RTM;xi  is  set  to  maxfRTMvXATS) 

•^  Fo-  w.t;i£s  if  TS  <  RTNl  x  ■  o:  TS  <  V>TMiXi.  tbe  vt-nie  operanoc  is  rejeaed  and  the  issuing 
transacaoL  is  restar.ed  »-.tr  a  ofu  higber  times'^Tip.  otberskTse  tbe  »Tit£  is  executed  and 
V*TM  X  IS  sc:  IC  TS 

An  opuinizauon  car.  be  pjenormed  to  the  founh  rule  using  the  Thomas  Write  Rule  (TVk'R;. 
Tins  s:a:es  iha:  instead  cf  rejectinc  a  wTite  when  TS  <  VvTNKx ;  we  can  simply  ignore  it. 
Hence,  ur.'.e  Lha:  cr}  tc  place  obsolete  valjss  are  ignored. 

3J.2.2  MuItKersion  Timestamp  Ordering 

This  techj-.ic ue  is  based  on  keepL-.g  around  old  versions  of  the  data  object  x  and  results  in  an 
impro\emer.:  c'  n\  ?\-nchroniza:ior.  over  the  basic  T/0  [Reed  78].  Associated  with  each 
data  c*"jcc:  ji  is  a  se:  cf  R-:s  ard  a  set  of  <'VS'-ts.  valuo  (version)  pairs.  R-ts  record  the 
timestamps  of  read  operations  and  the  versions  record  tmestamps  and  values  of  executed 
wnte  operauor.s.  R^  svTichronizaiion  is  accomplished  by  applying  the  following  rules: 

1.  Le;  TS  be  'iie  timestamp  of  a  read  operaooD  on  data  objea  x. 

Tbe  read  operauoL  is  processed  b>  reading  the  version  of  .r  ^itb  tbe  larges'.  nnesuTTip  <  TS  and 
adding  TS  to  jt's  set  of  R-ls.  A  read  is  never  rejected. 

2.  Let  TS  be  tbe  amesiimp  of  i  wnte  opcnoon  on  daia  object  x. 

Let  ioteTva]''\^'i  be  ibe  interval  from  TS  to  tbe  smallest  W-ts(x)  >  TS.  if  any  R-ts(x)  lies  io  tbe 
intervalOi^'j.  the  oper^non  is  rejected,  otherwise  t  new  vereioo  of  x,  <TS.  oew  value>.  is 
created 

A  read  ignores  all  versions  with  timestamps  greater  than  that  of  the  read,  hence  the  value 
read  is  identical  to  the  value  it  would  have  read  had  it  been  processed  in  timcstamp  order. 
A  write  is  processed  by  creating  a  new  version  of  the  objea  unless  a  read  with  a  greater 
timestamp  has  occurred.  In  this  case  the  write  is  rejected. 
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3-3. 2J  ConservatJNe  Timestamp  Ordering 

Thai  IS  a  tschruque  lo:  elirr.ir.aur.c  me  possib:l:r>  of  cor^'icung  ojxrauor.s  and  henc; 
elirnir.a:L".g  •-".e  r.eec  :c  restar.  rar.saCwCr.s  '^eca■-:5^  of  such  corJ"iic:s  rBerr.steL".  S*"'].  Tr^i 
approach  however  provides  less  concurrency  than  Lhe  basic  T/0. 

The  fiiT.damenta]  idea  underlymg  conservative  timestampmg  is  simple:  No  operation  is  ever 
performed  until  i:  car.  be  guaranteed  that  it  can  not  possibly  cause  a  con£ia  (and  therefore  a 
restan)  at  any  time  in  the  future.  Ln  oLher  words,  a  request  for  an  opcrarion  from  transaccon 
T  is  delayed  undJ  's.c  system  knows  that  no  confliring  requests  are  received  from  older 
n-ansacuons.  Conflicts  are  eiiminaied  Dv  scnalLang  all  opjcraaons  at  each  site,  not  jus: 
Lhose  operanons  'iiat  would  otherwise  conflict. 

TT-.I5  siruaaon  m.ay  'dc  improved  considerably  by  mroducmg  the  concept  of  ransaction 
classes.  T.'ansactirn  classes  are  defined  b>  a  read  se:  and  a  A.-.-.e  se:  Ir.  irj.s  case  ir.e 
operations  are  delayed  until  no  m.ors  ope.-anons  in  the  readset  or  writese:  vi:*_h  a  smialler 
timestamp  need  to  be  performed  a:  vanous  sites. 

3.33  Synchronization  Techniques  Based  on  Optimistic  Control 

The  basic  idea  of  optimusuc  methods  is  the  foUowLng;  Lns'.ead  of  suspending  or  rejectu-.g 
conflicting  operations,  like  in  2PL  or  T/0,  always  execute  a  transaction  to  complcaon. 
However,  wntc  operations  arc  performed  only  in  a  local  workspace.  Only  if  the  validation 
test  is  passed  at  transaction  commit  time  are  the  wnte  applied  to  the  database.  If  the 
vaiidanon  test  fails  the  temporary  writes  are  ignored  and  the  transaction  is  restarted. 

3JJ.1  Majority  Consensus 

This  algonthm  [Thomas  79]  assumes  that  a  copy  of  each  data  objea  is  stored  at  each  site. 
Hence  each  transaction  is  executed  completely  at  the  site  of  its  origin.  Another  assumption 
of  this  algonthm  is  that  Lhcre  are  no  data  objeas  that  are  wnnen  by  a  transaction  but  not 
read.  Each  transaction  receives  a  unique  timestamp  when  it  starts  execution,  and  each 


r^p^esen•.a•.:^e  c:'  each  data  ob;e:;  cames  me  tLT.esiamp  of  the  las;  transacnor.  uiuch  hai- 
vk-nn^r.  ir.'x  i;  Transactions  e\e;u-^  ir.  rue  phases.  In  the  first  phase  an  update  list  for  Lhe 
transacuor.  :>  produced  a:  the  home  s:te  It  contains  the  data  objects  in  the  transaction's 
read-set  wrJ-.  theL-  timestan-.ps.  Lhe  nev.  vaJucs  of  the  daia  objects  m  the  cransarjor.'s  v^nie- 
set.  and  tne  tLTiest^mr  of  the  transaction  itself. 

Ir.  the  second  phase,  the  update  list  is  sent  to  ever>-  site  to  validate  and  vote  on.  The  voting 
rule  foUowed  b\'  each  site  is  shour.  belou.  If  the  onginaung  site  gets  back  a  majonr>'  of 
positive  votes,  a  message  i.^  sent  tc  all  sites  lo  commit  the  updates  to  the  database.  Updates 
are  only  applied  i:  the  timestamp  of  Lhe  request  is  less  than  the  nmestamp  of  the  data  object, 
otherv.ise  the  update  is  ignored  (this  is  the  'TV>"R  mentioned  carlierj.  If  a  REJ  is  received, 
the  transaction  is  rejected.  aH  sues  are  informed  and  hence  the  upxiaie  list  for  that 
rransacaon  :s  disregarded  A  ?.\SS  \  ote  prevents  deadlocks  A  site  votes  PASS  only  uher. 
the  request's  base  va-iables  conflict  writ  these  of  another  pending  request  l*:  order  to 
Lnform  oLher  sites  of  a  potenua]  deadlock  situation.  The  request  in  quesuon  can  continue  to 
be  considered  until  sufficient  P.A.SS  votes  accumulate  to  prevent  majoritv-  consensus. 

Votinc  Rule 

1.  Conra.'e  the  omesiimps  of  ibe  reqjes;  reid-se;  witc  ihc  correspoDviiii^  tunesiamps  id  the  local 
daia.^asc  cop>. 

2.  Vote  REJ  if  any  value  m  the  rcad-sci  is  obsolete. 

3.  Voif  OK  and  mark  the  request  a5  penduig  if  eacb  viriible  is  tbe  read-set  is  current  and  the 
requesi  does  ooi  confLict  with  aii>  peeling  requests, 

4.  Vote  PASS  if  each  variable  m  the  read-sei  is  current  but  the  request  cooiLas  (has  common 
read-sei  vanables)  v^itL  a  pending  request  of  higtier  pnont>  (earlier  omestimp). 

5.  Oiherwose  f concurrent  confbct,  louver  pnont>),  defer  voang  and  remember  the  rrques!  for  liter 

reconsideranon. 


3J.3.2  Distributed  Certification 

One  copy  of  die  data 

Tnis  IS  a  dismbutec  u.-ne -based  aigo-Lhrn  which  operates  by  exchangu:g  cenificauor. 
informauon  during  the  commit  protocol  [SLiha  85].  UrJikc  the  previous  algonthm  it  allows 
distributed  transactions  ;a  master  transaction  at  the  iruaatmg  site  and  subtrar.sactions  at 
different  sitesV  A  read  timestamp  and  a  wnte  timcsLamp  is  maintained  for  each  data  object. 
Transactions  may  read  and  update  data  item^  freely,  storing  any  updates  mto  a  local 
workspace  until  comm::  time.  For  each  read,  tne  transaction  must  remem'5«:  the  wr.te 
stamp  associated  with  the  item  v. hen  it  was  read.  Vv"nen  all  subrrans actions  are  com^pieted 
and  have  reponed  back  to  the  master,  the  transacnon  is  assigned  a  glooally  unique 
timestamp.  This  timestamp  is  sent  to  the  subtrans actions  sue  in  the  "prepare  to  commit" 
message,  and  it  is  used  to  locally  cer:if%  all  its  read  and  untes  as  follows:  .A  read  request  is 
certified  if  the  version  that  was  read  is  still  Lhe  c-jxrcnt  version  and  no  \*Tite  with  a  newer 
tLmestam.r  h2s  been  locally  certif.ed  .A  v.r.t£  request  is  certified  if  no  later  reads  have  been 
certified  and  subsequently  committed  and  no  later  reads  have  been  locally  cemfied  already. 

Man\  cories  of  the  data 

Tms    req-ires    Lhat    sues    -Aith    representatives    of   the    c-n   also   participate    wrJi   the 

cemficaiion.  Updaiers  simply  certifv'  the  set  of  wntes  they  receive  at  commit  time. 

3.3.4  Comparison  of  the  Three  Methodologies 

The  locking  approach  may  easily  result  in  deadlock  requiring  deadlock  resolution  or 
detection.  The  timestamp  approach  is  deadlock  free  but  may  require  transaction  restan, 
another  expensive  process.  The  optimisuc  approach  is  based  on  the  assumption  that 
conflicts  arc  rare  and  therefore  most  transactions  are  validated  (few  rollbacks). 

Performance  analysis  of  the  2PL,  Basic  T/0  and  distributed  certification  was  conducted  by 
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[Ca-T>   SS'aj  L-  rse  coniex:  of  di'^r-iojied  database  systems.    Tne  foLouinc  conclusions 
vkhere  reached' 

•  ;PL  and  d:sribjted  certification  dominated  Basic  T/0  m  tcmis  of 
fjcrformance. 

•  NMier.  the  cos:  of  sending  and  receiving  messages  uas  low..  2PL  uas  the 

sur>enor  performer  cje  to  its  avoidance  o:'  transacDon  restart. 

•  V."nen  Lie  message  cost  v.as  high  and  data  was  replicated,  distributed 
cen.ificauon  outperformed  2PL  due  to  us  ability  to  exchange  the  necessary 
SNTichror.izanon  information  usmg  only  the  messages  of  the  two-phase  commit. 

3.3.5  Other  Concurrency  Control  Schemes 

Many  systems  CNeptune,  Gv-pss!  that  are  characterized  b>  long  transactions  use  version 
merging  tc  resoJve  \ersion  conflicts  that  ma\  anse  because  of  concurrent  long  user-dnven 
transacDons  The  meihods  proposed  require  the  user's  intervention  to  merge  versions 
together  These  schemes  fail  to  take  nto  account  the  need  for  senalizability  ir.  some 
siruauons.  SoniC  fue  system.s  provide  mechanisms  for  automatic  merging  of  versions. 
Various  strategies  have  been  proposed  to  resolve  merging  confuas: 

•  Conf.ic:  resolunon  rules 

•  Data  Fiov.  [Reps  ^T, . 

•  Some  choice  i?  made,  bu:  a  comment  is  also  included  indicaung  the  nature  of 
the  conflict,  or  Lhe  descnpuon  of  the  nature  of  the  confliCT  is  placed  in  a 
separate  documcnt- 

•  The  user  is  interactively  asked  to  decide  which  version  to  keep. 

3.4  Security  and  Protection 

Implcmcntaaon  of  protecrion  mechanisms  thai  permit  sharing  fall  into  two  categories 

[Salt2er75]: 

•  Capability  Systems 

•  Access  Control  List  Systems 
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3.4.1  Capability  Systems 

A  capabilia  is  an  identifier  for  a  shared  objea  thai  also  grants  nghts  to  perform  ccoain 
operaiiofLS  on  the  object.  Capabuuies  are  rspicaUy  represented  b\  a  b:t  sequence  consisting 
of  a  unique  identifier  for  the  object  and  a  specificarion  of  access  rights  to  the  objea.  A 
capabilirv'  ma\  be  presented  to  the  system  in  return  for  an  object.  Capabiliiies  m.ust  be 
secure  and  unforgabie. 

The  capabiiiry  system  has  as  r.s  chief  vurues  its  inherent  efficiency,  simplicity  and 
flcxibiLty.  Efncienc)  comes  from  "Jie  ease  of  tesung  the  \al:d:r>  of  a  proposed  access,  i: 
the  acccsser  can  present  a  capability,  the  request  is  valid.  The  simplicity  comes  from  the 
natural  correspondence  beru'e«n  the  mechanical  properties  of  capabiliues  and  the  semantic 
properties  of  addressing. 

The  potential  problems  with  the  capability  system  are  revocation  of  access,  'jncontrolled 
propaganon  of  access  and  inability  to  review  access.  Once  a  capability  has  been  given  to 
some  one  u  cannot  be  disabled.  It  is.  however,  possible  to  put  time  limits  on  capabilities  so 
that  they  expire  after  a  given  penod  Ln  time.  Capabiliues  may  be  distributed  to  other  users 
without  the  knowledge  of  the  creator  of  the  object.  If  the  user  id  is  incorporated  in  Lhe 
capability  then  only  the  users  with  the  appropriate  user  id  can  use  the  capability,  asstmiing 
thai  one  user  can  not  impersonate  another  user. 

3.4,2  Access  Control  List  System 

An  access  control  list  is  a  list  maintained  for  each  objea  in  the  system  indicating  the  users 
or  domains  that  have  access  to  the  objea  and  the  operations  pcrmined  for  each  user  or 
domain. 

Access   control  list  systems   overcome  the  problems  of  a  capability  system  but  has 
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LTiplemer.-.anor.s  probierr.'  o:  ;is  our.  Search  through  ar  access  coniro;  hs:  rr.a\  oe  a  tune 
cor.sumL-.L  proces-  .\jc:tr\er  alocatior.  of  space  I'o:  access  conro!  lists,  uhirh  car. 
chance  u-.  ;er;rJ-..  car.  be  2  forrr^idabie  LTiplementation  probiem. 


Chapter  4 
Literature  Survey 

Our  litcramre  survsy  covers  a  wide  range  of  dismbuied  sysiems.  Tne  systems  are  divided 
into  three  categones:  dismbuied  reiaiional  daiahases,  ojject-onenied  databases  and 
h\pcnext  systems.  Our  concern  :s  to  explore  the  approaches  to  object  sharing  adopted  by 
oLher  systems,  the  concorrency  conn-o!  schemes  used  and  the  update  propagation  schemes 
followed. 

4.1  Distributed  Relational  Database  Systems 

Distnbuted-INGRES 

Distributed-INGRES  [Stonebraker  "9]  v.  as  developjcd  a:  •j'.e  Uruversirv-  of  Caiifomia  at 
Berkeley,  as  a  disnbuted  version  of  the  relanonal  database  system  INGRES.  It  uses  2- 
phase-lockjng  for  concurrency  cono-ol.  Deadlocks  are  detected  and  resolved  wld^  a 
centralized  deadlock  detector.  "  describes  the  concurrency  conaol  and  consistency  of 
multiple  copies  of  data  m  Discributed-ENGRES.  The  basic  approach  is  primary  copy  2PL. 
Note  however,  thai  the  commercial  product  ENGRES/'STAR  as  of  1987  did  not  suppon 
Data  Replication.  RTI  has  commined  publicly  to  such  an  enhancement  in  the  future. 

R*  is  a  prototype  system  [Haas  82]  developed  at  the  IBM  San  Jose  Research  Lab  in 
California.  It  uses  2-phasc-locking  for  concuirency  control.  Deadlocks  arc  detected  and 
resolved  using  a  distributed  deadlock  detection  mechanism.  When  a  deadlock  is  detected, 
its  resolution  consists  of  aborting  one  of  the  transactions  m  the  wait-for  cycle.  R*  does  not 
suppon  data  replication,  however,  an  alternative  to  replication  was  introduced  in  the  nodon 


cf  snapshots  Snapshots  pressr.:  £  vjfv.  of  the  database  (possib!>  remote  uhich  v-as 
cor.s:ste-.-_'>  re  — e'-e:  a:  so— e  ra-s:  iir-.e  ar.d  which  is  peno<i::al;\  'rerreshe:!'  but  not 
updated  orJine. 

POREL 

POREL  [Neuholc  82]  is  a  distributed  database  systerr.  developed  at  the  Umvers:r%  o: 
Scungar.  Concurrenc>  conn-ol  is  done  b\  2 -phase -locking,  and  locks  are  kept  uniil  the  end 
of  transacuor.s.  In  order  tc  avoid  deadlocks,  locks  are  ordered:  there  is  a  toul  ordering  of 
sues,  and  lock  request.-  car,  no:  be  granted  at  one  site  until  all  higher  pnonry  locks  ar? 
granted  POREL  supports  data  rep.icanon  and  uses  a  vanauon  of  the  pnmars  copy 
approach  ic  propagate  updates.  Update  transactions  need  to  lock  exclusively  the  pnmarv' 
copy  and  pen'orm  updates  there.  Tne>  also  create  an  "intention  list'  a:  the  pnmar\-  site  that 
contains  the  updates  tc  be  sent  t:^  other  sues  At  aU  other  sites,  copies  are  marked  invalid. 
Copies  are  updated  b>-  a  differsr.:  ~ansacuon  which  is  started  either  when  woridoad 
condiuons  are  favorable  or  v-hen  a  read  transaction  must  make  a  "consistent"  read. 

SDD-1 

The  SDD-1  protor>-pe  [BemsteLt  80],  de\elopcd  at  the  Computer  Corporation  of  America. 
was  the  tlrs:  prototype  of  a  distributed  database  management  system.  Concurrency  control 
in  SDD-1  is  achieved  using  the  conservative  timcstamp  method.  This  mechanism  is  not 
deadlock  fre<  and  the  usefulness  of'conflict  graph  analysis  in  a  rcaJ-life  environment  has 
not  been  demonstrated.  SDD-1  supports  data  replication  and  uses  distributed  update 
propaganon  (write  alJ).  This  means  that  alJ  copies  of  the  data  arc  updated  before  the 
transaction  conmits. 

ORACLE/STAR 

ORACLE/STAR  [Gref  87]  is  a  commercial  distributed  database  system  developed  and 
marketed  by  Oracle  Corporation.     It  docs  not  suppon  data  replication.    It  uses  2-phase 
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locking  at  ±c  record  level  to  rcsolv-  uTiie-u-nte  conf;;c:s.     Read-Wnie  conf.:c:s  ar; 
allowed.  I.e..  wntsrs  do  no:  block  readers.   Oracle/Siar  uses  deadlock  deteccor.  as  oppose: 


'0  isadlock  rr?\ 


^esc;^e  ceaiocKS- 


Table  4-1  summenzes  'Sit  relevan:  fearures  of  the  discrlbuitd  relarionaJ  daiabases  above. 
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Not 
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UpcU:e 

Propaganoo 


Deadlock 

Prjv-nted 

V-aj-.-for 

AnaJvsu 
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No 
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rRecord  Level) 

Not 

Required 

Deadlock 
Detecaoo 

R* 

No 
Soapshou 

2  ?ha.se-LodQ::E 

Non 

Refresh 

D'.sr-.bu-.ed 
Deadlock        ; 
DetficnoD 

PCR£L 

Yes 

2  ?!M<!e-i,r)cJrng 

Vininoc  of 

Pnmiiy 

Copy 

Deadlock 
PrevenaoD 
ordfrmg 
locks              j 

Tabic  4-1:  Disnbu'.ed  Dat^base  Fearures 
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4.2  Object-Oriented  Database  Systems 

There  are  ruo  genera!  approaches  tc  impiementmg  a  shared  object  space  (hierarchv): 
c«nnralized  o:  disnbuied.  Present  pro:cr.7>es  falJ  into  one  of  these  genera!  caiegones  Tne 
foliow  L".e  IS  no;  ar  e>J".2usuve  s-zr\f\  of  prescn:  protor\-pes.  however  i:  gives  a  flavor  for 
the  vaner>-  of  protors-pe  s>s:ems  bcL'ig  implemented. 

GEMSTON'H 

Ser\io  Logic's  GemStone  [Purd\  87.  Maier  87]  adopted  the  centralized  approach  to  obiect 
shanng.  Tne  Gerr.Si-r.:  objec:  ser.  e:  connects  to  vanous  workstations  thiiough  a  local  area 
network.  It  ciirren*J>  does  no:  allow  a  database  to  be  distributed  among  several  GemStone 
ser^■ers.  Memoc  execution  car.  be  performed  either  by  executing  messages  remotely  on  the 
GemStone  server  or  b;-  copying  an  object's  state  to  the  workstation  local  cache  for 
marupiiiation.  Objects  are  represented  b>  depuues  that  decide  whether  to  forward  messages 
to  GemStone  or  cacht  ne  object  state  and  execute  the  message  locally. 

Stone  provides  secondary  storage  management,  concurrency  control,  auihonzailon, 
transaction  m.anagement.  recovery  and  supp>on  for  associative  access  of  objeas  Gem  sits 
atop  Stone  and  adds  the  capabilities  of  compiling  methods  into  b\iecodes  and  exccuang 
thai  code,  user  authentication  and  session  control.  Pan  of  the  Gem  layer  is  the  virtual 
image:  the  collection  of  classes,  methods  and  objects  supported  by  the  objea -oriented 
system. 

Stone  suppons  multiple  concim-ent  users  by  providing  each  user  session  with  a  workspace 
thai  contains  a  shadow  copy  of  the  objea  table  derived  from  the  most  recently  committed 
object  table,  called  the  shared  table.  As  objects  are  changed  in  a  session,  the  shadow  object 
table  adds  new  nodes  that  are  copies  of  its  shared  objea  table  with  the  proper  changes.  An 
optimistic  control  scheme  is  used  to  check  access  conflicts.    'VMien  Gcmstone  receives  a 
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commi:  message,  i:  notifies  all  depuues  of  iis  intent  to  commit.  Each  dcp'-r>  tncr.  Gushes 
any  modified  cached  state  to  GemSior.e.  Stone  checks  for  read-^nte  and  \>.-nte-viTite 
conflicts  with  cransacuons  Lha:  have  commir.cd  since  me  ume  Lhe  ransaction  began.  I: 
there  are  none,  the  shade  -  objea  table  of  the  session  is  treated  as  if  it  were  "n-ansparent"  on 
the  enz^es  thai  have  not  been  modified,  and  is  overlaid  on  Lhe  most  recent  version  of  the 
shared  table.  In  this  way,  the  changes  made  by  the  committing  session  are  merged  with 
those  of  other  transactions  thai  committed  after  Lhe  commirting  transacuon  began.  If  the 
transacnon  fails  to  commit.  Lhe  changes  in  its  shadow  table  are  discarded  ar.d  each  deputy  is 
told  to  invalidate  its  cached  sute.  Tne  developers  are  currentjv  exploring  Lhe 
implementation  of  locking  and  versioning  on  top  of  the  shadow  scheme. 

IRIS 

Hevs-lett-Packard  Laboraior.es*  L-.s  [Fishman  S"]  also  chose  Lie  csr.ral-zed  approach.  It 
implements  the  L-is  Data  Model,  which  falls  ur  Lhe  general  category  of  object-onenied 
models  that  suppon  bjgh-ievel  structural  abstracuon,  such  as  classification, 
generalizatioa'spwcialuaiion,  and  aggregation,  as  well  as  behavioral  absn^cuons. 
However,  the  Ins  Storage  Manager  is  a  convenaorul  rclaiionai  storage  subsystem..  The 
capabiliues  supported  by  the  storage  manager  include  the  dynamic  creanor.  and  deleuon  of 
relations,  transaction  management,  concurrency  control,  logging  and  recovery,  archiving, 
indexing  and  buffer  management. 

The  developers  arc  actively  exploring  extensions  to  the  storage  manager  to  support  long 
transactions  common  in  design  applications.  A  version  control  mechanism  is  proposed  is 
the  basis  for  concurrency  control  in  design  applications.  Users  would  be  allowed  to  check 
out  versions  for  extended  manipulation.  This  prevents  further  access  to  this  objea  by 
others.  A  higher  level  locking  mechanism  is  proposed  to  sujjpon  concurrency  control  for 
Al-based  applications.  This  provides  a  hierarchical  lock  structure  with  intention  locks,  as 
well  as  conventional  read  and  wr.te  locks. 


Disirib'jtej  Obier:  Ser^  c: 

Texn-onLX  La^oraiones's  [Pone:  88]  adopi&c  the  dismbuie-d  approach.  b>  impicmcnung  a 
lou-le\e!  disno'^ted  object  ser\e:  ir.  uhjch  the  gjobaj  object  space  15  discnbated  across 
cuer.i  workstations  and  objects  migrate  to  the  sites  where  they  are  used.  This  server  is 
intended  to  fcrrr.  me  iov.es;  ia>e:  of  an  object-onented  system  tha:  wiii  completeh  insulate 
the  user  from  the  pnrmtive  mode!  of  objects  provided  by  the  server.  The  server  provides  a 
shared  object  space  of  persistent  objects.  The  ufjper  layer  of  the  objeci-onented  system  wiE 
augment  this  model  to  provide  such  concepts  as  ty-ping,  message  passing  and  mhentance. 

Tlie  genera]  architecrure  of  the  s\siemi  consists  of  a  network  of  workstations.  Objeas  are 
stored  at  workstations  where  the>  are  used  Shared  objects  are  located  by  communicating 
to  a  name  server.  Objects  migrate  from  one  site  to  another  for  manipulation.  Concurrency 
control  for  shared  objects  is  anamed  via  a  variant  of  two-phase  locking.  A  shared  object 
must  be  obtained  before  11  can  be  accessed,  i.e.,  the  object  must  migrate  from  a  disk 
manager  (loczl  cr  remote)  into  the  session's  object  server  memory.  Access  to  this  shared 
object  15  blocked  until  the  session  relinquishes  it.  The  system  provides  low  level  version 
conn"ol  m  terms  of  historical  objects  that  are  immutable  and  maintain  time  of  creation. 
Tne\  are  explicitly  created  to  capture  the  state  of  the  objea  a:  any  moment  in  ume. 

Distributed  Smalltalk 

[Decouchant  86]  descnbcs  the  design  of  "k  distributed  objec  manager  which  allows  several 
Smalltalk-80  systems  to  share  objects  over  a  local  area  network.  Single  copies  of  objects 
arc  present.  Remote  access  is  done  through  the  use  of  symbobc  links  "proxy  objects"  that 
contain  information  about  the  locauon  of  the  object  Objects  then  migrate  for  local 
manipulation  and  associated  proxies  are  updated  indicating  the  objea's  new  site.  The 
design  docs  not  address  concurrency  control  to  pjcrmit  simultaneous  access  to  objects. 
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ObServer 

Observer  [Hormck  87]  is  a  persistent  objea  store  thai  is  currently  used  at  Bro\vn  Uruvcrsin.- 
as  the  backend  of  an  objcCT-onented  database  system  (ENCORE)  and  as  Lhe  storaee 
manager  for  an  objea-onented  interactive  programming  environment  (GARDEN). 

Objects  arc  clustered  into  segments  ai  ObServer.  Objea  access  by  a  client  results  in  the 
transfer  of  the  enclosing  segment,  if  not  already  present  at  the  client  workstauon.  Segments 
were  used  to  reduce  communicanon  traffic  m  object  transfer.'  ObServer  suppons  an  object 
replicanon  facility,  i.e.  ar.  objec:  may  be  placed  in  more  than  one  segment.  Moreover,  rue 
clients  may  have  copies  of  the  same  segment.  The  system  guarantees  automianc  ujxlatc  to 
all  copies  of  an  object  in  the  vanous  segments.  It  also  guarantees  thai  a  client  always 
accesses  the  latest  commirted  copy  of  an  object  through  the  use  of  timestamps.  Timesiamps 
are  given  to  transferred  segments  and  used  objects  in  the  segment  by  ObServer.  If  an  object 
is  updated,  the  changes  are  sent  on  to  Lhe  ObServer.  Timestamps  are  sent  to  be  anached  to 
the  copies  of  the  object  to  indicate  the  new  commit  time.  If  another  client  tries  to  access  an 
outdated  copy  of  the  objea  (difference  in  timestamp  of  object  and  scgmcnil,  the  oirrent 
copy  is  requested  from  the  server. 

ObServer  uses  a  comprehensive  locking  scheme  to  provide  concurrency  conffol.  The 
scheme  allows  objects  to  be  locked  in  a  range  of  locking  and  notification  modes.  The 
various  modes  permit  clients  to  access  (read,  write)  an  object  in  a  restrictive  or  non- 
restrictive  manner.  The  non-restrictive  mode  allows  cUents  to  share  unconunitted  changes 
made  to  an  objea.  Communicaiion  mode  allow  s  a  lock  holder  to  be  noufied  of  the  status  of 
an  objea,  including  requests  from  other  clients  for  that  objea  or  a  committed  update  from 
another  client. 


^Dne  of  the  basic  ideas  for  unproving  performance  in  objea-oriented  programming  is  thai  related  objects 
ire  clustered  together  m  physical  memory. 
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POSTGRES 

[Sionebrake:  86.  Rov.e  S6j  take  the  approach  of  stohng  a  shaiec  object  ruera:cr.\  l-^.  a  nexi- 
gensrai:or.  reianor.a:  database  mar.agemsn:  system  POSTGRES  POSTGRES's  extensions 
to  the  RDMS  L-.cIude  means  of  supporting  complex  objects,  of  allowing  new  daiar\-pes  and 
of  supporting  aleners.  tr.gger-  and  general  rule  processing.  The  use  of  an  RDMS  has  Lhe 
advantage  of  elimmaung  Lhe  need  to  implement  an  object  manage:  that  supports  shared 
access,  maintains  data  integnt>  and  resiliencN,  controls  access  to  objects  and  maintains  data 
consistenc\ .  As  objects  are  referenced  by  the  application,  a  run-time  system  retrieves  them 
from  the  database.  Objects  retrieved  from  the  databsise  are  stored  in  an  object  cache  in  the 
application  process  so  thr  subsequent  references  to  the  object  will  not  requLT  another 
database  rctncval.  Object  updates  are  propagated  to  the  database  and  to  other  processes 
that  have  cached  the  object.  .AJeners  nozf\  the  system  that  an  objea  has  been  ujxiated. 

Table  4-11  ^ummar^es  the  relevant  feamres  of  objea-orienied  databases  above. 

4.3  Multi-user  Hypertext  Systems 

Note  cards 

Notecards  [Tngg  86]  is  a  hv-pencxt-based  idea  structuring  system.  The  basic  objea  is  an 
electronic  notccard  containing  text/  graphics  and  images.  Individual  notecards  can  be 
connected  to  other  notecards  by  arbiuarily  typed  links,  forming  nerworks  of  related  cards. 
Distributed  Notecards  allows  users  simultaneous  shared  access  from  their  workstations  to 
notcfiles  residing  on  any  machine  in  the  nerwoik.  Distributed  Notecards  provides 
contention  resolution  at  the  level  of  individual  cards.  The  system  allows  any  number  of 
users  to  simultaneously  read  and  display  of  a  given  card.  However,  permission  to  make 
modifications  to  the  card  is  restricted  to  one  user  ai  a  time.  All  readers  of  the  card  are 
notified  when  modifications  arc  made.    Readers  are  provided  xhrcc  levels  of  modification 
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Obiec!-On--.:e<l  Cen:rL-zsZ  -s  Conrj.-rtr.cy  V-rsioninj 


GEN'.STCNT 


CoULIL'i 


I?J5  Cicra^zcd  Lockizt  Ym 


D:s  Obj  Histoncal 

S«r.'er  !  Obi;r^ 


Dis~.b'j'^-  Disr-.bj'.sc  Uojcao*-::  No 

SmailTiLx  (Ont  Cor\ 


iM;gra::on 


03  Server'  C^craiizs:  Comcrencnsive  Y;s 


ENCC?^ 


•  r  :,--■- - 


LocIgee  Y;s 


Table  4-11:  Fear-res  of  ObjcCT-Orienred  Daiabases 
notices.  The  reader  is  novSitd  (l)  when  someone  has  declared  ar.  mtenuor.  tc  modif>-  ihz 
card.  ''2  v^her.  's:t  j^T.'.t:  arrjal!v  ur.ies  '--.e  rr.od_r.ed  card  ar.d  '3  '.^her.  a  'AT.ier  deletes  a 
card.  The  systerr.  provides  no  special  mechariisn:  for  dealir.g  w:'_-  rr.odif>-  collisions  a:  'Jie 
individual  card  level;  exclusive  wntc  pemnssion  is  SL-nply  allocaied  for  an  urJirr-ied  per.od 
on  a  firsKome,  first-ser\ed  basis.  Notecards  has  no  suppon  for  versions. 

Nerr.r-ie 

Neprune  [Delisle  86]  dcfi-ies  '-he  noaon  of  ccniexis  to  support  muln-pcrsor.  cocperarive 
effons.  A  context  is  coliecdon  of  nodes  and  links.  A  mechanism  is  provided  to  merge 
different  contexts  togc'iier  to  create  a  new  context.  Contex*^  arc  used  to  enclose  version 
histones  of  objects  ar.d  Y.cr.zt  suroor:  concurrent  access.    .A  context  is  use-d  as  a  rnvate 
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workspace  fcr  rr.2.-^ir.c  updaies.  the  \o:zl  updates  wiL  evenruaUy  be  merged  v,ith.  another 
master'  con:e\:    Conflicts  rr.a>  arise  iS  &  modificatior.  uas  made  to  the  mas:e:  contex:  Lha: 
would  be  obscured  l*"  loca]  updates  were  merged  with  the  master     Tne  system  is  able  ic 
detect  me  conilicts  bu:  i:  is  up  to  the  user  to  resolve  them. 

Gs-psy  [Cohen  8S]  is  a  programming  suppon  environment  build  on  top  of  an  obiect- 
onenied  operating  system.  Tne  foundation  of  the  system  is  the  Version  Manager,  which  is 
used  to  store,  organise,  and  selecnvely  retrieve  versions  of  objects.  MuJuple  users  arc 
supponed  b>  the  V»'orKspace  Manager.  The  Workspace  manager  provides  a  protected 
environmen:  for  v.orking  on  pr.\ate  versions  Objects  are  clustered  into  workspaces  that 
define  user's  access  r.ghts  to  'iie  o'^jects.  Objects  are  not  replicated  but  various  version  and 
version  branches  for  an  object  exist.  Versions  created  inside  a  workspace  are  private  to  the 
workspace  and  are  no:  pubhch'  \  isibie  until  they  are  released  from  the  workspace. 

To  create  a  nev.  private  vers]on.  a  user  must  first  be  anached  to  a  workspace,  and  then  must 
lock  a  branch  o^  a  version  group.  OrdmarUy  only  one  user  can  be  attached  to  a  given 
workspace  Houever  additional  workspace  access  controls  f>cnTut  concurrent  access;  users 
who  take  advantage  of  this  flexibility  have  to  depend  upon  synchroruzauon  mechanisms 
outside  those  provided  by  G\-psy  (e.g.,  informal  messages  indicaung  who  is  using  what). 
Qose  and  weak  models  of  coopjcrauon  are  provided.  Qose  cooperation  allows  the  creator 
of  the  workspace  to  specify  whether  authorized  users  may  access  the  workspace 
concurrendy.  Weak  coojscrarion  allows  user  to  access  private  versions  with  specified 
access  rights  This  allows  coworkers  to  get  a  sneak  preview  of  a  needed  object  before  it  is 
released. 

Merging  of  versions  is  not  presen'Jy  implemented  in  Gvpsy.     The  design  proposes  to 
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suppor  t>-p)e-spec:fic  rr.erge  v.  ;•_-.  ca.-a.-netc.iz;d  operations  thai  'jse  various  srratccics  tc 

handle   conflicts.      Poss:b.e    s-aieg:es    L^clude   cont'ict   resol'uucn   r^es   or  Lnteractive:\ 
quen-'ing  'asking  L-.e  user 

Notes 

Even  though  Notes  is  not  a  h\-pcrtcxt  system,  its  suppon  of  replication  makes  it  an 
interesting  system  to  look  ai.  Notes  [Greif  88]  is  a  group  commurucaaon  system  that  is 
used  by  people  to  share  textual,  numenc  and  graphical  uiformauon.  The  system,  operates 
on  a  local  area  ner^».  ork  of  personal  com.puters.  Notes  is  based  on  document  manager  that 
provides  perm.anent  storage  lor  free-form  and  serru-strucrmrd  objects  of  arbiira.'y  size. 
These  databases  m;a>  be  replicated  a:  different  sites  allowing  rephcas  of  each  document  to 
exist.  Notes  replicanon  ensures  eventual  consistency  of  the  documents  in  all  replicas.  The 
database  sites  comjnunicate  to  \erjH  ihat  Lhey  have  Lhe  latest  cop.es  of  ahe  daiabase:  if  not 
the  nev-er  version  is  obtained  from  the  remote  database. 

Optimistic  concurrency  conn-ol  is  used  to  detect  and  signal  occurrences  of  multiple  updates 
to  a  single  version  mstance  of  a  document  (in  the  same  database )  and  fjiaUy  converge  the 
versions  to  a  SLngle  version  of  an  updated  document  (by  asking  the  user  whether  he  wants  to 
overwrae  an  existing  version).  The  system  resolves  conflicts  with  different  versions  of  a 
document  ai  another  d  ax  abase  site  by  choosing  the  version  Lhai  has  been  edited  and  saved 
most  often.  Access  control  lists,  may  be  used  to  control  concurrent  updates  in  a  number  of 
ways:  (1)  to  ensure  thai  changes  can  only  be  made  to  a  single  mastfir  copy,  and  (2)  ensure 
thai  changes  can  only  be  made  by  authors  of  the  document. 

Table  4-III  summ.arizes  the  relevant  features  of  the  distributed  hypenext  systems  above. 


-6?- 


Concurr:r,c\ 
Conrc: 


\  trsior 


NoiecanL- 


N;  RepbcaucT 


Locking 

ConiLcisi 


No 


No:  apjphcibie 


Nepcuiic 


DismDJted 
Nc  Rephcauor 


\  srsion 
Conn-o! 


Yes 


Performed  b\  Use: 
Ehfference  deiecaoc 
proMckd 


G>7?> 


Cencraliiei 


Lockinc 
Versioris 


Yes 


Performed  bv  User 


Note? 


Distributed 
RerLcaoDC 


Opumisn: 

ConcurrcncN 

CoDcrol 


Versions 
crcaied 
iDiemiUy 
bur  oo; 
mainuined 


No;  appbcabie 


Table  4-111:   H\-pcnexi  Fea*  j-es 
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Chapter  5 
Object  Lens  Revisited 

In  :his  chapter  v-f  rr.airJy  present  a  descripdon  of  Objer.  L«ns.  For  those  readers  viho  art 
familLar  with  objea-onenied  database  and  h>7>c.-:ex:  systems  w-e  wlI  indicaie  lear^es  o: 
these  systems  'iha:  Objer.  Lens  shares.  W-  \x-AL  then  present  fear^-es  specific  to  Object 
Lens  that  will  play  a  major  roie  'si  our  choice  of  the  appropnate  object  sharing  scheme  for 
Disn^buted  Object  L^ns. 

5.1  Object  Lens  as  a  Hypertext  System 

Object  Lens  fits  fo-LL'  of  the  s-j.  fearjj-es  of  an  ideali.zed  hyper.ext  sys'ism  enumera'^d  Ln 
[Conk^iTi  8"].  Tne  feardres  present  in  Object  Lens  arc: 

•  "Vi'indo'^s  or  :h£  screen  co'resporj  :o  nodes  in  the  database  on  a  one-to-one 
basis".  Tne  nodes  m  Object  Lens  are  trie  objects  and  objects  have  display 
windows. 

•  "U'ii^'oMj  can  contain  any  number  of  link  icons  v>hich  represent  pointers  to 
other  nodes  in  the  database".  Objea  display  windows  contain  a  number  of 
fields  and  values  m  these  fields.  The  values  can  be  frt€  text  combined  with 
link  icons.  Gicking  on  '-he  Imk  icon  causes  the  system,  to  find  the  referenced 
objea  and  open  an  object  display  window  for  it  on  the  screen. 

•  'The  user  can  easily  create  ney>  nodes  and  links".  Object  types  and  instances 
are  easy  to  create  through  a  tempi  axe -based  user  interface. 

•  'The  database  may  be  braised".  The  user  in  Objea  Lens  may  navigaie  the 
objeCT  space  by  following  links  and  opening  windows  successively  to  view  the 
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conten:      A  user  ess.  ajer\    lis  5\stem  for  objects  v.ith  par.icula:  arr-.bjte 


\a.i:; 


S2  Object  Lens  as  an  Object-Oriented  Database  System 

Objcc:  Lcr.s  proNides  ar.  m:erface  to  an  objea-onente<i  daiabasc  by  enjoying  the 
characterisnrs  of  object-oriented  systems  [Bobrou  86].  These  charaaensncs  are; 

•  each  object  includes  a  coliecuon  of  fields  and  field  values,  as  well  as  embedded 
objects. 

•  each  object  has   a  se:  of  actions  tha:  can  be  pwrfomied  on  it  by  sending 
messages  berveen  objects. 

•  objects  are  arranged  m  a  hierarch>  of  increasingly  specialized  type  with  each 
t\T^  mher.tL-.c  r.slds.  ac::?r.^  and  other  propenies  from  us  parents. 

Moreover.  Objec:  Lcr.s  provides  a  simple  v.a>  to  perform  datasase  quenes;  users  can  create 
agents  tha;  scar,  the  objects  m  one  folder  and  inscn  links  to  selected  objects  into  another 
folder    The  rj'es  m  the  agents  specif\  the  cnteria  for  selecting  objects. 

5-3  Object  Lens  Specific  Features 

In  addiuon  to  the  objea-onented  features  and  hypertext  feamrcs  of  Object  Lens,  the 
following  specific  characterisucs  influence  our  choice  of  an  Object  Shanng  Scheme  for 
Distributed  Object  Lens. 

1.  Naive  Users.  Objea  Lens  is  geared  toward  non-prograrrcrung  users.  This 
makes  user-interface  a  major  component  of  the  system.  The  user-interface 
model  influences  what  aspeas  of  object  sharing  are  exposed  to  the  user. 

2.  Agents.        Object  Lens  supports  the  creation  of  rule-based  "agents"  that 
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process  mformanon  automatically  on  behalf  of  the  user    TTiese  agents  car.  be 
triggered  by  everii-  s-ch  as  the  modificauon  of  a  particular  object. 

3  Semistructured  Objects  Each  object  :s  a  coUecuor.  of  fields  and  field 
values,  however  the  user  may  fill  m  as  much  or  as  Utile  informauon  in  the 
different  fields  as  they  desire.  Fields  are  not  typed  and  the  values  can  range 
from  free  text  to  a  link  to  another  objca  to  a  combinanon  of  both. 

4.  Customizable  Folders.  Objects  may  be  collected  in  customizable  folders. 
These  folders  can  be  m.aintained  manuiliy  or  by  an  agen:  Quenes  are 
executed  on  the  objects  in  the  folder  in  the  same  manner  as  quenes  are 
executed  on  tables  Ln  relational  databases. 

5.  Version  Maintenance.  .As  a  tool  for  umplementing  cooperaave  work 
applications.  Object  Lens  should  suppor.  the  Maintenance  of  different 
versions  of  objects. 

5.4  Using  Object  Lens 

Object  Lens,  like  us  predecessor  Lnformation  Lens  [Grant  8"],  makes  extensive  use  of 
mformanon  exchange  (Ir^eral  text)  using  specialized  semistrucrared  electronic  mail 
messages. 

Creating  semistructuied  objects  requires  "defining  a  collection  of  fields  and  field  contents. 
The  fields  are  defined  by  creanng  a  new  object  type  in  the  rvpe  hierarchy.  Note  that,  the 
new  objea  will  inherit  fields  from  its  parent  in  the  hierarchy.  The  inherited  fields  can  be 
renamed  or  their  display  supjprcsscd.  Additional  fields  may  be  added. 

Once  the  object  type  is  defined  (for  example  PERSON*),  objea  instances  can  be  created  by 
filling  in  the  fields  in  a  displayed  object  window  corresponding  to  object  type  (e.g., 
PERSON'),  hence  creating,  for  example,  JOH.N  and  TIM.  The  contents  of  an  objea's  filed 
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mc>  be  a  \-J\t.  to  anoLher  obisct  Tnis  11-^:  r;a>  be  expanded  to  appear  a;;  ar.  embedded 
o'-'fr:  L-  ihr  er.:".?;L".r  objec:.  Object  msiances  ma>  be  modified  b\  ediur.r  me  vk  ir.dou 
d:spia>  corresporidiT!;  i?  'i-.e  object  Tms  interacnve  ediur.c  of  objects  mav  take  or.  Lhe 
order  of  minutes  to  hojri.  Actions  ma>  be  invoked  on  the  objea  from  the  command  bar 
shov.r.  across  the  trr  of  L'.e  displayed  object  windov. .  There  are  several  kinds  of  actions. 
incluGLng:  actions  that  appl\  tc  the  editing  window  such  as  close,  move  and  shape,  and 
actions  that  apply  to  the  object  such  as  save  o:  add  link.  These  acuons  take  on  the  order  of 
subseconds  to  execute  Figure  5-1  depicts  a  displayed  object  form  of  a  Person  object  in 
Ob'ect  Lens. 


•,»<"m-l»iw»  1 9nr  Jo»«  •>«# 
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»'rnSOM  K.im  VewL^i                                                       | 
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Keywords: 

Convnentt: 

Figure  5-1:  Person  object  in  Object  Lens 

Users  typically  do  no:  have  more  than  about  ten  objects  displayed  a:  one  time.  This  is 
basically  due  to  limited  screen  real  estate  and  the  incapability  of  a  user  to  work  on  many 
tasks  at  the  same  time. 


Folders  can  be  created  and  objects  can  be  added  to  the  folder  cither  automatically  by  an 
agent  or  manually  by  inserting  a  Unk  from  the  folder  to  the  objea.  Folders  can  be  displayed 
as  table?  or  trees.  Tables  shov,  the  values  of  seleaed  fields  from  the  objects  contained  in 
the  folder.  Trees  shovk  Lhe  links  bcrsvecn  different  objeas. 
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Agen:s  car.  be  created  tc  automaiically  process  irj'orr.auon  on  behalf  o:  ihe  user  .\r.  accn:. 
when  cnggerec.  aprhes  a  set  o:'  r-ies  tc  objects  l".  some  folder.  Rules  rr^>  foUovt  lirjcs  l- 
objccis  to  access  irJorrr.auon  lt  embedded  objecrs.  .\r.  agent  ma>  be  mggered  by  events 
such  as  the  addition  of  luiks.  arrival  of  nevi.  ma:!,  passage  of  the  hour  o:  pcrhars 
modificauon  of  a  cer.ain  field  in  an  object  (not  yet  implemented".  .A.  rule  contains  r*o 
par-s,  the  descr.ption  and  the  action.  Tne  descnpuon  specifies  the  par.enn  that  should  be 
matched  for  the  rale  to  f-'e  '"by  indicating  the  values  of  some  fields  of  the  object  unstances 
in  question,).  Tne  acuon  specifies  '-".e  action  that  snould  ''x  taken  if  the  rule  :"lrei.  such  as 
copy.  move,  delete  or  add  ke>  v-ord. 

A  use:  may  navigate  the  object  space  by  stamng  at  the  basic  folders,  such  as  the  folder 
contaLmng  all  folders  m  the  s>5tem.. 

Tne  rype  of  op>e:auons  that  are  of  interest  to  us  are' 

•  A  use:  opcr^.z  an  object  form,  editu-.g  the  conten'^  of  the  various  rlelds  and 
then  saving  the  changes. 

•  A  use:  addng  o:  deleting  a  lunk  from,  a  folder  to  an  object. 

•  Automatic  execution  of  rules  by  agents  on  objects  in  the  folder. 

The  later  r*o  take  on  the  order  of  seconds,  the  former  on  the  order  of  minutes  or  even 
hours. 
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5.5  Object  Len^  Archilecturt 


Odjsc:  Lens  cor.iair.?.  Lie  mod-ir>  'berenson  89]  depicte-d  l'-.  Fipsic  5- 
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Figure  5-2:  Architecture  of  Objec:  Lens 

Tnt  Obiec:  Mar.ac?:  is  curren'J>  buL:  or.  top  of  me  Xerox  objea-onentcd  pr?rramming 
erviropjner.:.  LOOPS,  LOOPS  keeps  track  of  all  classes  and  class-instances  and  the^-  links 
to  each  o'iier.  I:  also  keeps  crack  of  the  current  state  of  each  object  and  execute  the 
methodi. 

The  Vi'indow.  Manager  is  responsible  for  prcsenung  the  object  in  windou  form.  It  handles 
user-events  (through  the  window  display  command  bar).  Those  that  dcaJ  with  display  and 
prescnution  it  handles  internally  and  those  that  deal  with  objea  instances  it  passes  on  to  the 
Objea  Manager.  Garbage  colleaion  is  implicitly  performed  by  the  underlying  system.  An 
object  is  garbage  collected  when  there  arc  no  more  references  or  links  to  the  object.  This 
process  is  much  more  complex  in  a  distributed  system. 


The  Agent  Manager  :s  responsible  for  executing  agents.   It  maintains  a  clock  for  triggering 


--C- 
time-dr.ver.  events   ar.d   receives  messages   tram  '-he  Objec:   Mar.ager  about  nc'*   I'j^ks. 
updated  obK::s  ar.d  rr.ar.-dl.;.  rr-zgered  ager.'.S- 

Objects  are  curre.-.iiy  sa-- sd  p^.Tr.a.-er/w> ,  orJy  ir.  fLes  on  a  fiie  scr-e:.  Tne  nJes  need  lo  be 
loaded  for  Lhe  objects  to  be  defined  The  fjes  may  remain  on  ir.t  v-orkstanon  and  her.cs 
define  Lie  Object  Lens  object  space.  The  object  on  ±ie  workstaaon  will  net  sur^tve  syste— . 
crashes  (ihe>  are  not  persistent,. 

Object  Lens  is  presen'Jy  a  single-user  system.    TTie  set  of  objects  thai  a  user  knows  about 

are  those  on  h^s  v.orkstation.  Object  5ha.~_".g  .s  limited  to  shanng  tne  miormation  content  c'l 

the  object.  This  may  be  achieved  m  rwo  ways. 

•  MaiLng  literal  orjects  m  an  Object  Lens  message 

•  Loading  a  specif.ed  fie  created  by  the  expor^r  of  Lhc  object  a:  a  common  file 
ser.er  (this  m.ay  be  done  somewhat  ransparen-y). 

Tne  r'lrst  approach  is  m  a  sense  a  one  time  exchange  of  objea  information.  Any  future 
changes  made  tc  the  object  b>  the  sender  are  not  refieaed  in  the  other  objea. 

In  the  second  approach  the  user  is  reloading  the  state  of  an  object  every  time  it  is  modified. 
Propagation  update  is  done  tlnrough  a  cenral  fUe  server.  Tr-s  approach  also  allows  for  the 
previous  version  to  be  m.amtained  tlnrough  a  link  from,  the  current  new  version.  This 
unplemeniauon  is  siov,  and  is  mainiy  addresses  updaie  propagation,  only  one  of  the  many 
feanires  required  for  a  comprehensive  objca  sharing  scheme. 

5.6  Ad  example 

A  topical  application  in  Object  Lens  is  processing  incoming  mail  into  folders  according  to 
artributcs  of  the  message  such  as  the  subject  or  the  sender.  The  incoming  messages  are 
processed  by  an  agent  and  put  into  a  shared  folder  thai  is  accessible  by  a  number  of  users. 


Consider  the  fcUo-^  ir.g  exarr.ple  Ar.  acen:  BUG-MESSAGE-COLLECTOR  fiiiers  ai: 
incomirc  messages  ina:  are  re--.2_L-.ir.c  ic  bLjc  fj^es  and  Liser.s  therr.  in:o  the  shared  folder 
BUG-MESSAGES  .A.-:>  use:  u  i-„-.  ac-e>s  tc  the  folder  could  brow.se  throcch  and  read  Lhe 
messages  Nov.  consider  the  case  uher?  the  BUG-MESSAGE  folder  is  opened  a:  a  user's 
workstation,  An.y  updates  made  ic  tr.e  folder  by  the  agen:  BUG-MESSAGE-COLLECTOR 
because  of  incorrunc  messages  appear  in  the  opened  form.  Note  thai  earlier  v^e  suggested 
for  objects  such  as  a  PEIRSON  that  the  user  should  be  prompted  to  refresh  the  object  form.. 
V^'e  fee!  Aat  r.  v.ould  be  more  appropnate  in  the  case  of  folders,  for  links  to  be  added 
without  '_he  need  for  user  inter-^ent::^n  snce  folders  are  m  most  cases  background  processes 

It.  the  next  chapter  v.e  discuss  the  requirements  and  features  of  object  sharing  for  the  Object 
Lens  svstem,. 


Chapter  6 
Multi-user  Object  L«ns 

Distributed  Object  Lens  v.ill  allow  users  to  simulLaneousIy  share  access  from  their 
workstations  to  objects  residing  on  any  machne  attached  to  the  local  area  network.  Objects 
may  be  replicated  at  vanous  sites  to  improve  performance  and  availability. 

Distributed  Multi-User  Lens  v.  lU  have  the  foUou ing  basic  feamres: 

•  A  d:s~buted  obiec:  space:  Objects  ma>  x  iocaied  at  different  sites  in  the 
network  and  may  u-.  some  cases  be  tTansparen->  accessible  by  remote  Object 
Lens  users.  Hence,  objects  may  have  links  to  other  objects  located  elsewhere 
in  the  nerw.ork.  The  system  must  suppon  such  links. 

•  Concurrer.i  u se rs  Ir,  a  multi-user  s\'Stem..  one  or  more  user  may  concurrently 
access  the  same  object.  Trus  may  lead  to  loss  of  infornuuon  and 
modiScauons.  The  system  should  provide  a  mechanism  for  guarding  against 
such  anomalies. 

•  Protection  of  shared  Objects:  Access  to  objects  vars-  from  one  user  to  another 
depending  on  the  authonzaiion  of  the  user.  One  user  may  be  allowed  lo  only 
read  the  objea  while  another  is  allowed  to  read  and  modify  the  objea. 

We  will  first  explain  some  early  design  decisions  made  for  Distributed  Object  Lens.   Next 
we  define  the  terminology  we  use.     We  then  present  a  design  for  object- sharing  in 

Distributed  Objea  Lens  with  emphasis  on  the  following  features: 

•  Shared  object  creation. 

•  Shared  object  deleuon. 

•  Shared  object  protection. 


•  Shared  obiec:  mod;f:ca:ior.  iha:  accommodaies  concurrent  users 

6.1  Earl}  Design  Decisions 

The  goal  cf  the  firs:  proio:>-pe  of  Dismbuied  Objea  Lens  is  to  test  the  proposed  schemes 
for  objec;  sharu".:  Tne  choice  of  the  architecrure  a:  this  stage  is  of  sccondarN  imponance 
We  thus  assume  ar.  architecture  that  requires  the  least  effon  to  implement  and  that  most 
resembles  the  curren:  configiiranor.  Tne  configuranon  is  that  of  the  server  and  the  client 
bcLng  on  the  same  v.  orkstanon.  We  rely  on  the  local  disk  manager  of  the  underlying  system 
to  ac;  as  a  prjr^tive  object  ser^e:.  Tr^  avoids  the  need  to  implement  an  object  se:%e:  o: 
acquire  one  tha:  fits  the  spec  J";  cations  menuoned  ir  chapter  2.  We  need  to  buiid  the  chen: 
objeCT  manager  to  provide  the  features  of  object  sharing.  Many  of  the  duties  that  were 
assigned  to  the  objec:  server  n  chapter  2  will  nou  be  performc<3  by  our  designed  object 
manager. 

We  allow  replication  to  provide  fas:  ioca!  access  to  objects  when  desired.  Objects  ma\-  thus 
be  located  at  a  number  of  workstations.  Since  replication  is  supponed  there  is  no  need  to 
suppor.  nugraiior.  of  objects  Tnere  is  also  no  need  for  caching,  since  objects  are  located  at 
the  local  workstanon,  no;  a:  a  remote  object  server. 

The  objects  at  the  workstaiion  are  not  persistent  (m  case  of  a  crash  the  objects  need  to  be 
reloaded).  Future  prototypes  will  need  to  incorporate  persistent  object  stores.  This  would 
be  easy  to  add  in  this  architecnire. 


6.2  Terminology 

Conceptual  Ob'cc:  is  ar.  object  that  diitcdy  represents  a  real  life  ennr.'  such  as  the  person 
John  SmiLT.  with  pnone  number  5-i"-0T^l  and  address  100  Memor.il  i>:  Tr.ere  :s  a  or.e-:o- 
onc  relationship  between  a  conceptual  object  ard  the  real  life  counterpans. 

Obec:  I'-.srj.'-.ce  Tvas,  refers  to  object  entries  ir.  lie  objcct-onented  lang-aage.  Tnese  will 
have  Unique  Ob;ect  IDs.  However,  object-oriented  languages  do  not  guard  against  the 
occurrence  of  more  than  one  object  instance  for  a  conceptual  object.  Hence,  if  an  object  is 
duplicated,  a  new  object  instance  :s  creaie-d 

Ob'ec  Ins  ranee  Rer'eserrjr.ve  Tms  refers  to  distributing  Lhe  object  a:  different  sues  ir.  the 
nerwork.  Tne  different  object  instance  representatives  should  be  treaied  as  's.t  same  abject 
Instance,  Tms  is  imponant  if  we  are  to  allow  different  copies  of  the  object  instance  to 
physically  exist  at  different  workstations.  The  association  between  the  different 
representatives  is  essential  to  ensure  update  propagation  to  aH  representatives  that  exist. 
Object  LID  may  be  used  to  associate  each  object  ms'Jince  with  its  various  represcntanves. 

Ob'ec:  Instance  Vcsion  This  refers  to  a  version  of  the  object  instance  mentioned  above. 
This  pcrmiis  revisions  to  be  m.ade  to  the  object.  wiLh  possiblv  a  histon.-  list  of  all  outdated 
versions,  Tms  is  not  implemented  in  current  objea-onenied  languages,  but  may  be 
implem.ented  by  generaung  objea  LTDs  to  associate  the  different  versions  with  the  same 
objea  instance. 

Objea  Space:  A  user's  objea  space  consists  of  all  objects  thai  he  can  access  through  a 
series  of  links  directly  or  indirectly  from  the  inimd  node.  The  nodes  and  the  links  are 
arranged  together  m  a  nerwork  strucmre. 


Figure  6-1:  Object  DcfiruDons 

6.3  Objects  in  Distributed  Object  L^ns 

6-3.1  Shared  \s.  Personal  Objects 

An  objec:  in  distr.Duied  Objec:  Lens  is  cither  a  personal  objea  or  a  shared.  Shared  objects 
ma>  be  pubhc  or  pr.\  ate. 

Persona]  Object 

Associated  with  each  use:  m  the  Object  Lens  nerw'ork  is  a  set  of  personal  objects.  The  user 
is  solely  responsible  for  modifications  made  to  the  objects  and  is  solely  guaranteed  to  see 
those  modifications  Tnese  are  equivalen:  to  the  user's  objects  in  the  current  single-user 
Objeci-Lens  system. 

However,  a  user  may  create  a  new  object  instance  of  a  conceptual  object  and  give  it  to 
another  user  in  the  system.  Neither  the  creator  of  the  object  nor  the  system  is  responsible 
for  the  maintenance  of  the  object  instance.  The  new  object  instance  is  the  property  of  the 
receiver.  No  resmctior.  is  made  on  where  a  personal  object  instance  physically  resides.  It 
may  be  local  ai  the  owner's  workstation,  or  ai  a  remote  site,  such  as  a  database. 

Shared  Object 

Conceprjally  a  shared  object  is  one  to  which  a:  least  two  users  have  some  form  of  access. 
Sharers  of  the  object  are  guaranteed  to  eventually  se«  the  modifications  made  to  the  objea. 
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Each  Object  Lens  user  \>.ill  vi-v.  his  personal  objecis  plus  a  set  of  shared  oojecs     He  u-Z! 
have  fuli  access  r.g-.'.s  to  his  personal  objects,  but  a  var>-Lnc  rang;  of  access  r.gh:s  ic  me 
shared  objects. 

Consider  a  ruo-user  Dismbutcd  Ooject  Lens  syswm  as  shovvn  in  Fig-jre  6-2.  User's  A 
object  space  consists  of  the  objects  PROCESS,  LENSFOLDER.  TOM,  JOHN',  KE\TsV 
TASKX.  T.ASKMANAGER,  and  aca  T.  User's  B  objea  space  consists  of  the  objects 
PROCESS.  LENSFOLDER,  K£\'IN-.  TIM.  JOHN.  TASKX.  and  acct  K.  As  persona: 
objects  are  acct  T  ar.c  TASKMAN.AGER.  B's  personal  objects  are  acct  K  and  TIM-  Tne 
remainine  obiects  are  snared  ':?v  both  A  and  B. 


Figure  6-2:  Two-user  Dittibuted  Object  Lens 


6J.2  Private  vs.  Public  Objects 

The  distinction  between  private  and  public  objects  is  thai  of  authorizarion  and  secuhry. 
Authorization  descnbes  access  nghts  by  users  to  various  objects.  Access  rights  fall  into  a 
combination  of  the  foUov^Lng  ( Read,  Modify } . 


Public  Obiects 

As)\  user  l-.  Lr.t  D;5n-.:''jtec  Orjt::  Ler.s  ner^cri.  ha^,  all  access  nghts  to  ?ub'i:  Opiecis. 
Public  objects  arc  a  subse:  cf  shared  objects  Pubhc  obiec'.<^  are  sharec  b\  all  distributed 
Object  Lens  users  v.:±  full  access  nghts. 

Private  Objects 

A  pnvate  object  may  only  be  accessed  by  an  authorized  user.  Access  may  be  lirrured  to  ari> 
of  read.  modif>  or  delete.  Shared  objects  may  be  divided  into  sets  of  private  objects,  each 
set  adherjsg  to  authcrjiauon  requirements. 

.At  example  of  a  pnvate  object  is  the  LENSFOLDER  objea  in  figure  6-2.  Both  users  A 
and  B  haNe  access  to  it  beca'jse  the\  are  pan  of  the  LENS  group.  A  non-LENS  group 
member  will  no:  have  access  to  the  folder.  Hence,  the  LENSFOLDER  is  pnvate  to  Lens 
group  members  Moreover,  user  A  might  have  'delete"  rights  to  the  TOM  object  while  user 
B  only  ha^  '  read'  nghts  to  the  object. 

63.3  Local  \s.  Remote  Objects 

It.  Distributed  Object  Lens  objects  may  be  physically  located  at  any  workstation  in  the 
nerwork.  A  use:  rr.ay  access  objects  that  are  local  to  h:is  workstarion  or  that  arc  remote  at 
another  workstanon  or  pwssibly  a  database  ser\'er.  It  may  be  necessary  to  expose  this 
distincuon  to  the  user  to  explain  the  delay  tune  experienced  in  accessing  the  object.  This 
distincuon  is  not  as  impK)rtant  in  a  fully  redundant  implementation  of  Distributed  Objea 
Lens  (i.e.,  each  object  is  replicated  a:  every  site  in  the  nerwork). 


6.4  Creation  of  a  Shared  Object 

In  this  section  wc  \>.lLI  descr.'De  use:  mterface  for  crcaung  shared  objects. 

C'dnr.'".?  access  [c  a  Shared  Ob^e:  • 

The  actual  objea  is  created  m  the  same  marjier  as  objects  are  currently  created  in  Ob;sc: 
L«ns  (i.e..  using  ir.e  edi:o:  :c  ~^  \r.  w-.e  Si03  of  a  serru-structured  tennplaic  corresp>onding  to 
the  object  type;.  Once  the  private  object  is  created,  the  owner  may  decide  that  other  users 
should  also  have  some  form  of  access  to  the  object.  Informing  or  granting  access  to  the 
object  may  be  done  -".  one  o:  :ac  v. a>s- 

1.  The  creator  sends  a  Ler.s  message  :o  ano'Jner  user,  with  a  link  to  the  object. 
The  receiver  then  inser.s  a  hnk  to  that  object  into  another  objea  (e.g.,  a 
folder)  in  bus  object  spavi  T:^.z  receive-  ^.^-^  L.-'.sr..  o:  a:  a  future  time  resolve 
the  \_\rk_.  allowing  mm  tc  v;ev.  tr.e  contents  of  the  obiec:. 

2.  The  creator  insens  a  link  to  ihe  objea  m  an  object  Lha:  is  already  shared.  The 
system  can  possibly  notify  other  users  of  the  addiuon  of  diis  new  object.  A 
special  case,  and  possibly  the  most  comjnon,  would  be  the  mseraon  of  the 
link  into  a  "shared  folder". 

The  former  of  the  rwo  methods  is  appropriate  for  initialing  sharing  of  a  parent  (root)  objea. 
We  vtill  illustrate  the  rwo  methods  using  ihe  example  in  Figure  6-2. 

User  B  creates  a  task  object  TASKX.  User  A  m.anages  ai!  tasks  by  using  his  jjcrsonal 
TASKM.ANAGER  object  User  A  therefore  needs  to  have  access  to  TASKX  through  a  link 
from  the  TASKMANAGER  objea.  User  B  therefore  mails  a  message  to  user  A  with  a 
reference  to  the  TASKX  objea  (Method  I).  User  A  can  then  adds  a  link  from  the 
TASKMANAGER  objea  to  T.ASKX.  The  reference  may  be  later  resolved. 
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Tne  LESSFOLDER  fc'.ce:  is  shared  b>  all  users  (A  ar.d  B  ,,  This  Lmphes  iha:  al".  objects 
tha-  car.  be  reacr.ed  b\  tracLnc  iLiks  from  the  folder  arc  shared  b>  all  users  If  a  neu  use: 
joins  the  croup,  a  nev.  person  objec;  instance  (JOHN;  is  created  corresponding  to  the  user, 
and  a  lini.  ir  ine  ob'ec:  unstance  :?  Lisened  l".  the  LESSFOLDER  folder.  All  user?  uiT  nov. 
share  the  neu  objec:  instance  Tne  JOHN  person  object  was  made  accessible  to  other  users 
b\  inenng  a  Ilix  to  it  from  an  already  shared  object  LESSFOLDER  {Method  2). 

Resohine  Links 

Resolving  a  link  could  imply  one  of  rue  things  depending  on  the  desired  implementation. 

•  Creating  a  local  object  instance  representative  of  the  object.   Tne  shared  object 
becomes  a  loca.  object  and  future  accesses  will  be  made  to  the  local  copy. 

•  Remotel\   rerieN'ing  the  object  from,  iti  sue.     Tne  object  remains  a  remote 
object  and  furore  accesses  to  it  uiU  also  result  in  remotely  retnevmg  it. 

L'^PLE\fEMATIO\' 

Each  object  may  have  a  num'^er  of  object  instance  representatives  that  are  located  at 
different  sues.  A  unique  object  identifier  should  encompass  information  about  the  locanon 
of  the  particular  object  instance  representauve  and  ihe  objea  it  corresponds  to.  A  possible 
confiruranor.  for  the  system  uide  object  id  is  showed  m  Figure  6-3. 
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Figure  6-3:  System  Wide  Unique  Object  ID 

The  object  id  pan  is  used  to  associate  different  object  instance  representative  together.  The 
[Machine  Created  on]  field  of  the  reprcsentativcA'crsion  id  indicates  the  location  site  of  the 
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representanves.     The   [Time  CreaietTi  fields  allows  for  differer.:  v;rsions  to  ex:s:.     \\e 

carjiot  rei>  on  the  objec;  id  generated  by  the  underiyung  system  to  fit  our  requirements.  If 
the  underiying  system.  aJlcus  an  object  id  to  be  specified,  then  we  choose  to  spccifS  Lhe 
unique  object  ids  is  mennonec  above  .Anoiher  ait£m.an\e  is  to  build  one  level  of 
indirection  where  object  :ds  generated  by  the  system  arc  mapped  to  the  proposed  system 
wide  u.'uque  object  ids. 

Resolving  an  object  reference  translates  Lnto  a  read  request  direaed  to  the  object  manager. 
If  the  object  is  not  local,  the  ,'rr^chine  created  or'  field  is  used  to  direct  Lhe  read  request  to 
the  appropriate  object  manager  across  Lhe  network  at  site  [machine  created  on]. 

SnorTCC'^.:>-£  C'  P'O'OCO'. 

In  essence  a  user  is  granted  access  to  a  shared  object  by  providing  the  user  with  a  link  to 
that  object.  Trus  ".hanng  protocol  has  some  shcr.con-jnes: 

•  Unintentionai  Ljnks.  User  .A  might  unintentionall>  provide  links  to  objeas  he 
regards  as  personal.  For  example,  A  grants  B  permission  to  include  objea  "x" 
is  his  workspace,  however,  in  doing  so,  A  grants  B  permission  to 
uruntentionilly  include  .A's  personal  object  "\"  because  of  the  link  berween  "x" 
and  "v'. 

•  Propagation  of  Access.  User  A  has  no  control  of  who  else  might  get  access  to 
an  object.  For  exam.ple,  if  A  grants  B  pwrmission  to  access  object  "a'\  B  in 
turn  might  give  C  a  link  to  thai  object,  hence  allowing  C  access  to  objea  "a" 
without  A"s  consent. 

•  Revocation  of  .Access.  User  A  cannot  revoke  access  to  an  objea  to  which  he 
gave  out  a  luik. 


6.5  Deletion  of  a  Shared  Object 

Lr.  obiect-onenied  systems  obiecis  are  removed  from  memors-  using  a  process  called 
garbage  coLJectior.  Tne  efrec:  of  deleur.c  an  object  from,  a  users  object  space  is  removing 
his  links  to  thai  object  OrJ>  v.her.  there  are  no  more  links  pomnng  to  an  object  will  the 
obiec:  ge:  garbage  coI:ec;td  lr.  a  d;s~Dutec  envL'onment,  marters  are  no:  as  simpie 
Multiple  users  ma\  have  Imks  to  an  object  Many  of  these  links  are  from  remote  sues. 
Hence,  the  reference  count  that  maintains  the  n'jmbe:  of  local  references  to  an  objea  should 
be  extended  to  include  remote  references  The  object  is  garbage  collected  when  bo'J~.  the 
local  and  remote  references  are  zero. 

Tms  implies  rev.r.:Lig  the  underlying  garbage  colleaor.  Trus  is  hard  tc  impicmen:  and 
might  be  unnecessary  for  the  iruual  protonpe.  An  alternative  simpler  scheme  would  be  to 
use  the  current  underlying  garbage  collector  However,  the  object  manager  has  to  also 
maintain  local  representatives  (m  the  fonn  of  links)  of  remote  objeas  pointing  lu  the  local 
shared  objects  These  links  are  dropped  when  the  clien^LS  indicate  that  they  have  dropped 
these  links. 

6.6  Protection  of  a  Shared  Object 

Thus  far  we  have  explained  how  a  user  may  get  a  link  to  an  objea  but  we  have  not 
specified  the  type  of  access  the  link  provides.  Distributed  Object  Lens  should  provide  for 
controlled  access  to  an  object  The  question  is  how  such  infomiation  is  declared  and 
enforced  ? 

In  Chapter  3,  section  4  we  saw  two  models  of  protection,  one  independent  of  objea  naming 
(Access  Control  List)  and  one  dependent  on  objea  naming  (Capability  System).  We  will 
examine  how  each  of  those  models  would  be  tailored  to  the  E^istribuied  Objea  Lens 
environment. 


CapabiJ:r\  Svsien 

The  object  LID  descriDed  earhe:  v>.ould  also  consist  of  a  spec  •J":  cation  of  access  nghts  tc  the 
object  (perhaps  containing  one  bit  fo:  each  class  of  operations  applicable  to  ihe  object  i. 
V.'hen  a  nev,  object  is  created  b>'  a  user,  the  object  manager  constructs  the  OUID  of  the 
object  with  a  full  set  of  access  rights.  The  modificauon  of  access  nghts  may  be  made  pan 
of  the  object  manager  duues.  The  objea  ,:.e.,  the  OLTD)  ls  presented  to  the  objea  manager 
with  a  specificauon  of  the  nght3  required.  The  new  OLTD  remmed  would  have  a 
diminished  set  of  access  r.ghts  t  otherwise  users  wrJi  few  nghts  could  apply  for  more  >.  This 
ne-A  OLTD  co'^ild  be  m^^ed  tc  i_fferer.:  ^ser?  ±a:  may  now-  have  rcsmctive  access  to  the 
objea. 

This  scheme  as  it  stands  assumes  that  users  do  not  forge  links  or  impersonaie  another  user. 
Users  would  do  this  to  uicrease  their  access  rights  or  to  get  access  to  objects  that  they  arc 
not  authorized  to  get  access  to.  For  our  purposes  of  designing  a  research  system  assume  no 
malicious  intent  on  the  par.  of  the  users.  An  authenticanon  mechanism  such  as  Kerberos 
could  cleanly  be  added  to  a  producnon  system  to  guard  against  possible  forgery  and 
impersonation. 

Access  Concrol  List 

A  list  IS  associated  with  each  objea  specifying  the  authorized  users  and  the  operations 
permitted  for  execution  by  the  users.  Such  information  is  separate  from  the  QUID  and  is 
maintained  by  the  objea  manager.  Hence,  when  a  user  requests  access  to  an  objea  in  some 
specified  mode,  the  objea  manager  verifies  thai  the  user  is  allowed  such  access  before 
returning  the  objea.  From  the  user's  point  of  view,  when  creating  the  objea  he  needs  to 
specify  the  users  thai  have  access  to  thai  objea  and  their  access  rights.  Another  option 
would  be  to  specify  a  set  of  rules  that  govern  access  to  the  object  These  may  be  easier  to 
formulate  and  have  the  effea  of  defining  protection  domains  for  the  object.  This  however, 
may  be  inefficient  because  it  requires  resolving  the  rule  every  time  the  objea  is  requested. 


Comr2.-:sor,  o:  CarabL'-.r.  -Based  and  Access  Conr-o!  L;s:  Svs:ems 

A  C2pabil:r>-bis.ed  pro:er::or.  model  does  no:  guard  agair.s:  ihe  shoncomir.gs  mentioned  ir. 
Lne  earlier  semen  Ar.  access  conrroi  bai.ed  proiecuor.  model  incurs  a  lirce  overhead  'J".a' 
migh:  be  unnec€ssar>  m  a  lot  o:'  cases.  Given  the  hierarchical  strucrure  of  the  object  space. 
Lhe  c'jesnor.  arises  unether  a  child  object  inhents  the  propcnies  (access  nghis'*  of  the  parent 
objer.  Tms  ma>  be  appropriate  in  some  cases  but  not  all  It  is  possible  to  allow  this  as  a 
default,  but  expliciij>  overv-nie  it  by  describing  a  new.  set  of  author^atior  rules  for  the 
child  object. 

Hvbr.d  Mode! 

It  IS  more  appropriate  to  use  access  control  lists  in  the  restnctive  sense  as  opposec  to  the 
permissive  sense  Tnc  access  control  lists  will  contain  informauon  regarding  users  that  are 
not  allowed  access  to  the  object,  A  hybrid  implementation  is  the  most  adequate 
Restrictive  access  control  lists  are  used  to  overcome  the  deficiencies  of  a  capability -based 
system..  It  ls  important  to  guard  the  object  against  undesired  users  who  have  somehow 
obtaLned  a  Il-tI;  to  'the  objea.  Hidden  links  to  personal  objects  may  be  proteaed  using  an 
access  conn-ol  list  that  denies  access  to  all  users  except  the  creator  of  the  objea.  Hidden 
links  may  'tx  protected  m  rwc  cn'ierent  modes: 

•  The  unauthorized  user  may  have  knowledge  of  the  existence  of  a  certain 
object,  and  hence  can  sec  it  in  its  icon  form.  The  user  however,  is  not 
pcTTTUttcd  to  view  the  contents  of  the  objea.  To  follow  on  the  example  in 
Figure  6-2,  an  unauthorized  user  may  be  permitted  to  sec  that  Tom  is  a  member 
of  the  Lens  group,  but  is  not  pcrmirted  to  get  more  information  about  Tom  by 
view  ing  the  contents  of  TOM  person  objea. 

•  The  unauthorized  user  is  oblivious  to  the  existence  of  the  objea.  i.e..  the  links 
are  hidden  Hence,  when  the  unauthorized  user  looks  at  the  LENSFOLDER 
folder  he  will  not  sec  a  link  tc  the  TOM  person  objea. 
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The  laner  mode  is  much  harder  to  Lmplement.  It  requL-es  that  the  object  ser\'er  performs  the 
following  additional  step?  before  retumLng  the  objea. 

•  FoUov^s  ar.d  resoives  ans  '.irJcs  '--.e  requested  object  may  have, 

•  verifies  if  access  is  pcnruned  to  these  embedded  objects. 

•  if  so  Lhe  links  are  kept  intact. 

•  cLherv-ise  rencve  the  links. 

Shared  .Aeer.ts 


Agents  in  Object  Lens  are  implemented  as  objeos,  and  hence  can  be  shared  like  any  other 
object  instance.  Consider  ar.  agent  that  operaies  on  tne  LENSFOLDER  folder.  Both  user  .A. 
and  user  B  have  access  to  the  agent  ar.d  hence  can  tr.gger  it  on  the  folder.  Hov>.ever,  user  A 
IS  restricted  trom.  seemg  some  object  ir.  the  LENSFOLDER,  namely  TTM.  The  outcome  of 
the  triggered  agent  should  differ  from  one  user  to  another.  Hence,  a  triggered  agent  should 
have  the  same  access  nghts  to  the  objects  as  the  user  that  mggered  ;t.  A  mggered  agent  is 
analogous  to  an  executing  program.  It  will  have  the  same  usend  as  the  user  who  triggered 
it.  Vvlien  the  rules  are  fired  and  the  acuons  arc  executed,  the  objects  thai  are  read  or 
scanned  arc  these  that  can  be  read  by  the  user. 

.Another  option  is  to  suppon  agents  with  parameter^ed  userids  that  may  be  set  by  the 
creator  of  the  agent.  The  default  is  for  an  agent  to  assurnc  the  userid  of  the  user  that 
triggered  it.  Otherwise,  the  uscrid  of  the  agent  may  be  set  by  the  creator  to  be  some  userid 
(e.g.,  himscifj.  Hence,  even  if  the  agent  is  tnggered  by  another  user,  it  scans  the  set  of 
objects  that  are  accessible  by  the  specified  uscrid.  This  is  helpful  in  giving  a  user  access  to 
the  services  of  an  agent  to  run  a  particular  query  without  giving  him  access  to  the  ennre 
underlying  folder.  The  user  will  only  have  access  to  the  objects  in  the  folder  thai  satisfy  the 
query. 
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Use:  Ir.ierface 

I.-,  accessing  an  obiec  a  use:  Me-J-s  the  corresponding  windc*  d:spia>  DependL-.g  or.  Lhe 
users  access  r.z'TM.  the  appropriate  con^jnands  are  sh?v.T.  or.  the  comn^and  ba,'  Fc: 
cxa.-nplt.  ar.  td::  conmand  shou  s  orJy  lT  'j-.s  use:  has  the  nght  to  modif>'  the  obiec;  and  a 
delete  conrr.ar.d  shoui  orJ>  i:  the  user  has  the  nghts  to  delete  the  object. 

Specif>'ing  restrictive  access  lists  is  an  extra  command  when  the  object  is  created. 

6.7  Modification  of  a  Shared  Object 

Objects  in  Objec:  Lens  car.  be  modified  either  interactively  by  the  user  or  automatically  b> 
triggered  agents.  Objec:  Lens  ccrrentJ>  supports  the  foUowLng  user-dnver,  commands  that 
result  in  a  change  in  the  objec:  space:  save,  add-Imk,  move,  close.  Users  may  edit  an  object 
and  save  the  chance >  or  add  ar.  item  to  a  folder.  Tnggered  agents  apply  a  set  of  rules  (rules 
can  also  be  applied  manually ;.  Vv"ner.  a  rule  is  applied,  a  collection  of  objects  is  scanned  to 
look  for  objects  thai  match  the  description  of  the  rule.  If  a  match  occurs,  the  aaion  part  of 
the  rule  is  executed  on  the  object.  These  actions  may  var\  m  complexity  (sec  secuon 
6.7.1.2  for  further  detail;. 

L-.  a  distributee  rr.-jl::-user  environmer.:  consistenc\  and  concurrency  are  of  paramount 
imponance.  Distributed  Object  Lens  should  provide  suppon  for  each  of  these  features. 
The  remainder  of  this  chapter  will  be  devoted  to  exploring  various  ways  of  proNiding 
concurrency  control  for  simultaneous  users  and  achic\'ing  consistency  between  different 
objcCT  instance  representatives  (if  present). 

Consistencv 

The  basic  premise  is  that  all  changes  made  to  the  objea  should  be  made  visible  within  a 
given  time  period  to  all  authorized  sharers  of  the  objea.  The  question  is  whether  the  update 
propagation  should  be  exposed  to  the  user  or  done  transparently  by  the  system.  This  is  only 
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an  issue  ;f  inzr^  are  different  cbjec:  instance  representative  of  the  object.   Tne  tm-o  options 


are. 


-  S'^'ste":  Guaranteed  Once  an.  object  '.s  mod'.fied,  the  system,  ruarantees  that  all 
sharers  of  die  ob'ect  evenr-ally  see  &ie  change  Goose  consistency  conirol). 
H?u  trjs  is  implementfid  depends  on  the  shared  objea  implementation  we 
choose  and  ihe  concurrency  control  desired. 

2.  E.T:;osed  to  user.  The  modifier  of  the  object  sends  a  message  indicaimg  the 
chancrs  tc  all  sharers  of  ±e  '?;sct.  I:  is  '-".en  up  to  the  sharers  to  modif>'  their 
objea  instance  represcntaiive. 

ConcurrenrN- 

The  system  should  allow  any  number  of  users  to  access  the  same  shared  objea  ai  the  same 
time.  It  is  viizl  m  such  a  siruaiion  tc  ensure  'jiat  concurrent  acuon  do  not  inicrfere  wiuh 
each  o±ers  operations.  Two  kinds  o:  ;onfucts  ma>'  ansc: 

•  A  Version  Conflict  that  res'ults  v. hen  different  users  are  accessing  their  object 
instance  representatives  concurrently,  but  are  modifying  different  slots  or  fields 
in  the  object.  Version  conflicts  can  'oc  resolved  by  merging  the  two 
representatives  together. 

•  A  Serial  12 abUiry  ConfliCT  occurs  when  two  or  more  concurrent  users  are 
allowed  to  access  the  same  slot  m  the  object  and  one  or  more  of  the  accesses  is 
a  modify  or  when  two  users  arc  pxrforming  modifications  thai  are  dependent 
on  each  other. 

A  concurrency  control  scheme  should  be  adopted  thai  vrill  resolve  such  conflicts.  Again 
the  concurrency  control  can  be  done  by  the  system  invisibly  or  visible  to  the  user.  Two 
possibilities  anse: 
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1.  S'-srerr  Guara-nieei  Tne  system  should  g^jaraniee  resolvng  conflicts 
Hence.  ar.>  transactions  iha:  res'Jt  ir.  a  conT.ici  should  be  abcned  and 
restated 

2.  User  AJerred  Tne  use:  is  alerted  of  a  conf.ic:  a5  soor,  as  i:  is  knovkT.  to  'jie 
sysiem.  It  is  \^'p  to  the  user  to  undo  the  actions  to  resolve  the  conflict. 

6.7.1  Transactions  in  Object  L€ns 

Vv'e  ulL  use  the  transaction  model  to  descnbe  the  rw.o  types  of  modificaiions  possible  m 
Distributed  Obiec;  Ler.>  A  transaction  is  defined  as  a  unit  of  work  consisting  of  a  sequence 
of  operations.  becLnrung  with  a  special  BEGIN_TRANS ACTION  operation  and  ending 
w  ith  either  a  COMMIT  operation  or  a  ROLLBACK  operation.  COMMIT  is  used  to  signal 
successful  tcrrrur.aticr.  'the  unit  of  work  has  been  successfully  completed).  ROLLBACK  is 
used  to  signil  unsuccessful  termination  (the  unit  of  work  carjiot  be  successfully  completed 
-  a  data  object  can  net  ':>e  read;. 

The  rwo  types  of  modifications  are  formal!)  descnbed  in  terms  of  transaction  as  such: 

1.  User-dnven  modiiicanons  are  performed  by  the  user  editing  the  objea  form. 
We  wiH  term  these  interacuve  transactions.  These  transactions  are  long-lived 
and  may  last  from  minutes  to  days,  i.e.,  the  time  that  elapses  between  opening 
the  objea  form,  making  the  changes  and  finally  closing  the  object  form  may 
be  days.  Moreover,  these  transactions  are  very  expensive  to  roll-back  and 
redo.  Interactive  transactions  wiU  overlap  more  frequently  because  of  the 
duration  of  the  transactions. 

2.  Agent-dnven  modifications  arc  performed  as  a  consequence  of  a  fired  rule. 
Rules  are  either  applied  by  triggered  agents  or  by  users.  We  will  tem:i  these 
automatic  transactions.   Tliesc  transactions  are  shon-lived,  i.e.,  last  no  longer 


ihar.    a    feu     seconds.       Automatic    transactions    are    comparable    to    daia 
processing  n-ansactions  m  database  systerr.S- 

V^  e  V.  lLI  iniuaHy  exarrLir.e  hou  ihe  various  s\Tichronizanon  techniques  proposed  for 
dismbuted  database  systems,  C.\D  ssstems  and  H>-penext  systems  may  be  unpiemented  to 
achieve  concurrency  control  for  mteractivc  transactions.  Accordingly  v-e  wd]  examuie  hov. 
these  techniques  may  be  used  to  achieve  concurrency  conffol  for  automanc  transactions. 

6.7.1.1  Interactive  transactions 

An  mteracuve  transaction  could  either  consist  of  a  simple  read  operauon  (opening  the 
object  form)  or  a  read  op^erauon  followed  by  edicmg  the  object  form  and  then  closing  the 
object  form  hence  savmg  Lie  changes  We  will  assume  Lhat  m  case  of  mod:5icaticns,  the 
transition  for  O,  to  0,^j  is  solely  based  on  Op  thai  is.  no  other  objects  need  to  be  read. 
Figure  6-4  shous  the  ruo  possible  sets  of  Literactive  transacuons.  Opening  an  embedded 
objea  IS  considered  as  a  separate  (not  a  nested)  transaction  Our  claLm  is  that  opening  an 
embedded  object  is  no  different  from  opening  any  other  objea  in  the  system.  The  user  may 
feci  that  the  two  transactions  are  related  and  may  require  to  ensure  no  interference  from 
other  users.  Vve  see  below  how  he  may  accomplish  this. 

R^(O)  Read 

RgfO)  Wg(0)         Modify 

Figure  6-4:  Imeracnvc  Transactions 

If  rwo  users  arc  concurrently  accessing  an  objea  the  following  three  scenarios  are  possible: 

•  Two  users  are  concurrently  reading  the  object  —  no  conflia  arises. 

•  Two  users  are  concurrently  modifying  the  objea  --  conflia  potentially  anscs. 
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•  Concun-cr.'J\    one   use:  is  readme   and  the  oihe:  n  modif>'Lnc   the  obie::  -- 
confiic;  ro:er.::j^;>  ar.ses 

Since  the  pcten:;aJ  for  confiir:  depcncs  or.  me  narurc  of  the  sim'jitaneo.:-  LT.erac'.:\e 
uansacaor..  the  mode  of  access  needs  to  be  cxpiiciuy  spiecified  by  the  user.  Ir.  marA  case> 
the  cor.f.icts  Lha:  ar.se  are  vcrsior.  confiicis.  not  senaiizabic  conflic'Li.  This  means  tha;  rv.o 
users  are  p>erforTrur.g  uidependen;  modificauons  to  the  object.  Tne  foDowmg  are  three 
examples  that  illustrate  the  Lhree  kinds  of  wv\  conflicts  that  may  arise  in  interactne 
transacaons. 

Consider  a  TASK  objec;  that  has  as  one  of  its  fields  [progress  repon].  The  contents  of  this 
field  IS  free  text  that  allov.  s  users  involved  in  the  task  to  wnte  about  ihcu  progress.  Two 
users  ma\  simaltaneousl>  edit  the  corresponding  objcCT  form  to  note  their  evaluauon.  Even 
though  both,  users  are  accessing  the  same  field,  they  arc  installing  independent  pieces  of 
free  text  that  reflects  their  evaluations.  VN'e  refer  to  this  as  a  version  conflict. 

Consider  a  PERSON  object  JOHN  Two  users  may  simultaneously  access  the  object,  one 
to  modifv  the  [phone  n'^m'i^e:]  field  and  the  other  to  modify  the  [salary]  field.  We  also  refer 
to  this  as  a  versicr  confuct. 

Consider  the  TASK  object  again.  Assume  that  rwo  users  arc  accessing  the  object 
simultaneously.  However  one  user's  comments  arc  dependent  on  the  other  user's 
evaluation.  We  refer  to  this  as  a  serializable  conflia.  Access  to  the  objea  needs  to  be 
performed  in  serializable  order. 

User  Interface 

One  opdon  is  to  let  the  user  specify  access  when  the  object  form  is  opened.  Hence,  a  user 
may  access  an  objea  either  to  Read  or  to  Modify.  Another  option  is  to  have  edit  as  one  of 
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ihe  bar  commands  on  the  object  form     Opemnc  Lhe  object  fom-;  is  an  indication  of  a  read 
and  clicking  or  the  ed;t  comjnand  is  ari  indicat:on  of  a  wnte. 

6.7.1.2  Automatic  Transactions 

So  far  we  have  seen  changes  in  the  object  space  iniaaied  and  explicitly  completed  by  an 
interacuve  user  thjough  Lhe  use  oi  object  fomis. 

Users  of  Objea  Lens  can  also  create  rule-based  agents  to  automatically  process  information 
content  of  objects  A  ru.e  cor.ststi  o:  a  descnptior.  and  an  acuon.  Description  sp)ecuies 
when  the  rule  sho'uid  firr  and  action  specifies  the  consequence  of  the  rjle.  The  matching  of 
a  rule  and  the  execution  of  us  action  m.a\  be  modeled  by  the  transaction:  Tp^  :  RiO;  -- 
R(O^)  ....  .AfO, )  where  .AfOj  >  can  either  be  a  sunpie  wnte  W(Oj)  in  the  case  of  actions  of 
the  form  (move  objea  to  folder,  copy  object  to  folder,  delete  objea  from  folder)  {Caieeory 

I  rules:  or  a  senes  of  reads  R(0;  ' R-'O^j)  followed  by  a  write  W(Oj)  j*.  the  case  of 

actions  of  the  form  {set  <vaj-:ab:e>  to  (calculation)}  (Category  2  rules).  Figure  6-5 
summarizes  how  rules  are  modeled  as  transactions,  There  would  be  a  number  of  reads  if 
the  predicate  (description )  pan  of  the  rule  consists  of  an  embedded  objea.  TTic  write  in  Tj^ 
is  dependent  on  the  value  of  the  object  read.  The  consequence  pan  of  a  rule  is  conditional 
upon  the  value  of  the  predicate.  Tms  means  that  rule  exccuuon  may  lead  to  senaluabie 
conflias  if  rules  are  allowed  to  interleave.  Rules  need  to  be  executed  atomically  to 
preserve  the  serial  order  of  the  cxeoinorv^  We  consider  rules  and  not  rule  sets  to  be  the  unit 
of  work. 

Category  1  Rules 

Catrgory  1  rules  perform  their  reads  on  any  kind  of  objea  but  jserform  their  writes 
specifically  on  folders  by  adding  or  deleting  links  from  folders.  The  write  operation  may  be 
viewed  as  an  append  operations,  hence  two  different  writes  may  happxn  in  any  order 
without  altering  the  resultant  folder.  This  means  that  ww  conflias  of  category  1  rules  may 
be  resolved  by  merging  the  two  modifications  together. 
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Figure  6-5:  Rule  execution  transactions 

R\^  conflicts  cf  ca!egc-^  1  rules  need  to  be  handled  with  much  more  care.  Recall  that  the 
cxecuaon  of  a  wnte  operation  of  a  rule  is  dependent  on  the  value  of  the  read.  Hence 
mterleavmg  the  execution  of  the  rw.  c  r^ies  such  that  the  read  of  one  occurs  before  the  vt-rite 
of  the  oLher  ma>  lead  tc  conflicts  and  inconsistencies.  V\;  illustrate  this  in  the  following 
example.  Consider  the  followmg  two  r^Ies  m  pseudo  form: 

•  If  obiec:  =  TOM  m  Folder  A  then  add  link  from  Folder  B  to  object 

•  If  object  =  TOM  not  in  Folder  B  then  remove  link  from  Folder  A  to  object 

These  two  rules  basically  ensure  consistency  between  Folder  A  and  Folder  B:  object  TOM 
is  either  in  both  folder^  or  none  of  the  folders.  Figure  6-6  shows  how  the  rules  could 
interleave.  The  first  rule  performs  Rj  and  Wj  and  the  second  rule  perform  R^  and  Wj. 
Initially  the  objea  TOM  is  in  Folder  A. 


In  executions  (Ij  and  (4j,  the  rules  are  performed  aiormcaUy  in  scnal  order.  Even  though 
the  outcomes  are  different,  they  arc  both  consistent  with  the  rules.  Hence  the  order  in 
which  the  rules  art  perfomied  atomicaUy  is  not  important  as  long  as  they  are  pcriowntd 
aiomicaUy.  Executions  (2)  and  (3)  dcpic;  the  uxong  outcome  if  interleaving  is  allowed.  Rw 
conflicts  of  this  type  may  be  resolved  by  serializing  the  execution  of  the  two  rules. 
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Figure  6-6:  Interleaving  of  Rules 

Categor^•  2  ruie? 

Le:  us  consider  the  second  categon-  of  rules.  T^:  R(0)   ...   [RfOj   ..  W(Ojj)j.     These 

procedural  ac-ions  are  more  comparable  to  database  transactions  and  in  most  cases  need  to 

be  serialized.  To  iilusuaie  this  consider  the  foDowing  rule  in  pseudo  form: 
•    If  objea  =  task  then  set  taskmanager. count  to  taskmanager. count  ♦  1 

and  consider  r^'o  agents  that  appl>  this  rule  v.hen  a  ne\^  task  object  is  added.  If  rwo  users 
concurrently  create  a  new  task  objea,  then  the  above  rule  is  tnggercd  by  rwo  different 
agents  concurrentlN .  If  the  execuuon  of  the  rules  is  not  serialized  one  task  may  be 
unaccounted  for.  The  net  affea  would  be  adding  1  instead  of  2  to  field  taskmanager. count, 
since  both  rules  will  read  the  initial  value  of  taskmanager. count.  Moreover,  the  actions 
performed  by  such  rules  are  not  as  simple  as  adding  links.  Hence  both  h/h'  and  rw  conflicts 
need  to  be  senaiized. 

6.72  Concurrency  Control 

6.7^.1  Time-Stamp  Ordering 

In  this  section  we  will  describe  how  timestamp  ordering  may  be  used  as  a  synchronization 
technique  L".  Object  Lens.  Object  access  is  analogous  to  the  current  Objea  Lens  interface 
("click  on  icon  "  to  read,  "Close,  Save"  to  write)  as  opposed  to  the  rwo  modes  required  if 
locking  is  used.    The  timestamp  of  the  transaction  is  recorded  when  the  user  opens  the 
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onec:  fcrrr.  Obiec:>  v,  :i:  also  ha\e  the  umesiamp  of  ihe  iaies:  read  (RTM'O  ar.c  tne 
tLTiesiamr  cf  Lhe  lates:  w.T.te    \^T7>.1  O;.). 

As  indi:a:ed  \r.  Cnap'.e:  ?.  Basi:  T/0  is  ori!>  ap^phcabie  \n  an  environment  where  orie 
represen:ar:ve  of  the  obtec:  exis:s  Recall  that  timestamping  is  an  opi.irnisuc  approach 
uhere  transactions  are  alloued  tc  p:o:tsc  urr^  a  conf.ic:  is  deteaed  (b\  comparing 
timesLamps).  then  one  of  me  transactions  is  aborted,  rolled  back  and  redone.  In  the  case  of 
interactive  transactions  fRfO  --  W(Oj;  this  implies  that  conflicts  are  detected  ax  commi: 
time  fwhen  user  saves  modifications,-  The  unte  is  rcjeaed.  A  user  only  finds  out  that  his 
modincations  can  no:  be  accepted  at  corrLTu:  (save)  time.  This  is  highly  undesirable  in  an 
interacuve  envu"onment. 

Timestamping  ma\  be  used  to  senaiize  rules  execuuon.  This  however  requires  that  rules  be 
re«xecuted  v.hene%e:  conflicts  anst  Timestamping  does  not  accommodate  for  the  special 
trearmen:  of  uvi  conflicts  in  categorv  1  rules. 

To  summar^e: 

1.  Timestamping  is  inadequate  and  inconvenient  for  Lnieractive  transactions. 

2.  Tunestamping   may   be   used   for  senakzing   category    2  rules.      Overhead 
incurred  in  mainianing  timestamps  and  reexecuting  rules. 

Another  limi'^uons  to  basic  T/0  is  its  assumpnon  of  one  copy  of  an  object.  Distributed 
Objea  Lens  would  mostly  likely  suppon  multiple  copies  of  an  object. 

6.7.2^  Optimistic  Concurrency 

Recall  thai  the  basic  idea  of  optimistic  concurrency  control  is  to  always  execute  a 
transaction,  then  validate  it  and  commit  it  if  the  validation  test  is  satisfied.  In  Distributed 
Certificauon,  a  wntc  to  an  object  is  rejeaed  if  any  later  read  to  the  objcCT  is  validated  ai  any 
other  site  that  contains  a  representative  of  the  object 

In  case  of  interactive  transactions,  this  means  that  writes  are  rejected  at  commit  time  if  a 


simuJtaneous  read  cr  wme  occurs  This  agair.  is  ncor.verjen:  ir.  ar.  u-.terarvAe 
environmen:.  Disr-.i^u-.ed  csr.:::canor.  rr.a;.  resoi'-e  v^-^  and  '-^  conflict  of  caisgor>-  2  rjies. 
I:  rr.ay  also  be  used  ;c  resolve  '-.■.  ccnfjc-s  bu;  :s  ur.abie  :c  reat  h-m  corilicts  of  categors-  1 
rales  as  append-only  cansaaions. 

Tnis  scheme  rr.a>  ':>e  LT.proved  if  Lie  grar.uianrv'  of  upxiate  is  rtduced  from  ar.  objer.  to  a 
siot  IT.  jie  object. 

D:f:e'er.ce  ber'A-eer.  3ai::  TO  ar.d  Dis~.b-:'.ed  Cerjjicanon 

Given  our  simple  mterac::ve  ransactions  ("Reads  or  Modifies).  Time  stamping  and 
Op:urust:c  Co.~.rcl  are  v-r.  i-sr^n  Tne  optimistic  connnl  descr.bed  above  -.nder  diesc 
condiuons  is  tr.e  mar.\  ccr^  '  vanauon  to  Basic  T/0.  This  observauon  is  no:  true  in 
database  system.s  v. here  transactions  consist  of  multiple  reads  and  \».Titcs  of  differing 
obje~s. 

From,  the  user  pom:  of  vie>*  bOwi  approaches  look  the  same.  Ho\J.ever,  since  cptimusnc 
control  makes  a  vtorkmg  copy  of  the  objea,  one  in  prmcipie  can  get  access  to  Lhai  copy  and 
only  make  the  necessar-  changes  to  resolve  any  conflicts.  This  idea  suggests  versions  as  a 
svTichronizatirn  technique. 

6.7.2 J  Two-Phase  Locking 

Two-Phase  Locking  was  described  earlier  in  chapter  3  inthe  context  of  distributed  daabase 
systems.  Several  'wechmques  (prjnary  copy  2PL,  centraiizad  2PL)  were  proposed  for  an 
environment  w.herc  several  representatives  of  an  object  exist.  Two-phase  locking  resolves 
rw  and  vw*  conflicts  by  blocking  read  and  wnte  operations  if  a  write  is  occurring,  or  by 
blocking  a  write  if  a  read  is  occurring. 

In  the  context  of  interactive  cransacnons  this  means  thai  if  a  user  is  modifying  an  object  no 
other  user  may  be  able  to  modif>'  it  or  read  ii.  Recall  thai  interactive  transactions  may  last  a 
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long  Dcncd  of  tune  (e.g..  a  couple  of  hours  i  Tms  means  that  other  users  uoL^d  ot  biocicec 
frorr.  seeing  or  moc::>uig  ar.  obiec:  lor  such  lor.:  penoCi  of  tLTie.  Tr^>  is  unacceptable  \r. 
cases  v-here  the  modli^ca3on^  to  an  object  are  independent.  It  is  however  necessar\  it. 
cases  of  dependent  modifications.  Locking  works  weL  for  senaiizabie  k-m  corilicts  be: 
imposes  unnecessa."  srncmess  m  the  case  of  indep^enden:  uvi  conflicts  Two-phase  locking 
n.'picaU)  block  reacers  li  a  mod:f>  operation  is  being  peii'ormcd.  This  again  is  too  strict  in 
the  context  of  interacnve  operations.  V>'c  would  prefer  that  readers  be  allowed  to  read  an. 
object  even  if  it  is  not  consistent  with  the  modifications  currendy  being  made  to  the  object. 

ScnalLzabUir>-  is  not  required  for  category  1  rules  vivi  conflicts.  Hence  locking  would  be 
unnecessary.  Locking.  ho\>.eve:,  would  be  appropnaie  to  resolve  n\  conflicts  of  category  1 
rules  and  serialize  the  execuuon  of  categorv-  2  rules. 

To  summarize: 

1.  Locking  is  toe  restrictive  for  most  interactive  transactions. 

2.  Locking  is  unnecessary  for  many  executions  of  category   1  rules.    Writes  do 
not  need  to  block  other  wntes  because  of  the  append  nature  of  the  writes. 

3.  Locking  is  necessary  to  serialize  execution  of  caiegorv  2  rules. 
Discussion  and  Issues 

Simila'-iT\  of  Difrerem  Locian^  Implemenianons 

In  all  cases  the  Lens  user  has  to  wait  if  another  user  is  accessing  the  object  in  a  conflicting 
manner.  The  user  is  notified  once  the  lock  is  released.  The  disadvantage  of  locking  is 
disallowing  access  to  an  object  for  lengthy  periods  of  time. 

Differences 

The  difference  anses  i.-  the  improved  access  tune  (because  of  local  access)  and  increased 
availabilit\'  in  the  case  where  "many  copies  of  the  object"  exist.  Replication,  however, 
results  in  ii  greater  message  overhead. 


Deadlock  Free 

Vv'iu".  our  mods!  c:'  L-.:srac:i\e  transacnor.s  there  li  no  nsk  of  deadlock.  Thj>  is  'c)ecause 
interacTive  rrar.saaior.s  arc  simple  (i.e..  do  no:  involve  readLng  or  modifv'ing  more  thar.  one 
objec'w.  This  is  noi  n-ue  for  automatic  nransacuons. 

GrgrtuJi'-tr.  0^ Lockir.o 

Tht  granularir.-  of  Lhe  locks  affect  &it  degre«  of  possible  concurrency.  Locking  at  the  slot 
level  viiil  res'alt  in  more  conom-ency  than  locking  ai  the  objea  level.  Objects  in  Object 
Lens  m-ay  be  hierarchical  m  structure,  i.e..  a  student  objea  may  contain  a  Link  to  a 
depamnent  object.  This  raises  the  question  whether  locking  an  object  means  locking  all  the 
objects  that  it  has  links  to.  If  so.  this  wiU  result  m  less  concurrency.  We  indicated  earlier 
that  we  chose  to  model  ihe  vieumg  of  embedded  objects  as  simple  non-nested  transactions. 
This  eliminates  Lhe  need  for  hierarchical  locks.  Locking  an  object  will  not  lock  all  us 
embedded  objects.  Embedded  objects  are  locked  when  they  are  accessed.  A  more 
appropnate  soiuuon  would  be  to  maintain  the  granularity  of  the  locking  ai  the  object  level. 
If  a  user  tnes  to  access  a  link  from  an  object,  he  may  do  so  in  two  modes  CRead  &  Modify). 
The  request  is  granted  if  no  conflicting  locks  already  exist  on  the  objea. 

6.7.2.4  Version  Control 

This  approach  (used  in  CAD  systems)  resolves  conflicts  by  merging  various  versions  of 
representahves  together.  No  waits  oi"  restarts  are  necessary.  Version  control  is  an  extension 
of  optimistic  concurrency  control  where  the  working  copies  are  made  accessible  as  new 
versions  and  validation  and  verificanon  are  performed  by  the  uaer  through  merging.  No 
system  known  to  date  is  capable  of  providing  automatic  merging.  Let  us  consider  two  users 
A  and  B  concurrently  accessing  objea  "x"  in  modify  mode.  Two  new  versions  of  "x", 
"xA"  and  "x£"  arc  created.  At  this  point  each  version  excludes  the  other  users  changes. 
The  two  versions  need  to  be  merged  into  one  thai  would  be  the  current  version  of  "x".  The 
question  is  how,  when  and  who  merges  the  rwo  versions  together.  The  possibilities  are: 
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•  The  tw.0  versior:;-  need  lo  be  merged  v. her.  a  user  anempis  tc  read  ' i '  and  sees 
more  '•s.ds.  ct.^  c^rrer.'  \ersior.  rreser.'. 

•  Tnt  luo  versio.-i  are  rr.erzed  b;.  ihe  \3s\  use:  to  comm::. 

The  disadvancace  of  version  contro;  is  iha:  it  provides  no  mechajiisrr.  to  resolve  senaiizable 
corJiias.  Trus  occur?  v.  her  changes  made  b>  one  user  are  dependent  on  changes  made  b\ 
another  user  uorking  concurrently.  Noucc  thai  in  this  approach  the  disuncuon  between 
object  instance  reprcsenianve  and  object  instance  version  becomes  vague.  The  distmciion 
is  made  zx-p'.'.zw  \i  a  lor.r  \ersior.  historv-  of  an  object  is  going  to  be  mamtained. 

6.7.2.5  Proposed  Synchronization  Technique:  Hybrid  of  Locking  and  Versioning 

So  far  ue  have  elirrunatec  tL-nestampLne  and  opamisnc  concurrency  control  as  suitable 
synchronizanor.  techjuques  for  mteraaive  transactions  in  Distributed  Object  Lens.  Locking 
is  suitable  to  avoid  senaiizable  conflicts  but  is  too  harsh  and  inconvemem  for  version 
conflicts.  Versior.  cor.CTo!  has  the  opposite  problem.  It  is  suitable  for  version  conflicts  but 
does  not  guard  agains:  senaiizable  conflicts  We  propose  that  the  synchronization 
technique  best  suitable  for  Distributed  Object  Lens  is  one  that  combines  both  version 
control  and  locking. 

Our  hybrid  synchronizauon  technique  uses  version  control  to  resolve  version  conflicts  and 
exploits  explicit  locking  to  resolve  serializable  conflicts  in  the  case  of  dependent 
modifications  in  interactive  transactions,  category  2  rule  execution  and  rv,'  conflicts  of 
category  1  rules.  The  locking  scheme  described  earlier  used  implicit  locking  enforced  by 
the  system  whenever  a  read  or  write  is  jjerformed  by  a  user  or  a  rule  transaction.  Explicit 
locking  allows  the  user  to  lock  an  object,  so  that  crucial  modifications  to  be  made  to  the 
objea  with  no  interference  from  other  users.  Another  user  trying  to  concurrently  modify 
the  same  object  would  be  informed  of  its  sutus  and  would  have  to  wait  for  the  lock  to  be 
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released.     Readers  however  will  not  be  blocked  and  will  be  allowed  to  read  the  latest 
comrmrted  version  uiih  an  indication  that  it  is  being  modified. 

Interactive  Transactions 

A  user  is  also  provided  v-iih  ±s  option  of  modifv'ing  the  objecrt  without  locking  u.  A 
laiSsez-faire  amr-de  i.version  controlj  is  adopted  here  and  concurrent  users  are  aiiowed  ic 
modifN'  an  object  lt  their  own  workspace  and  create  a  new  version  of  the  objea.  At  commit 
time  the  new  versions  arc  broadcast  to  all  sites  that  have  a  rcpresentauve  of  Lhe  object.  A 
use:  is  notified  of  the  incoming  version  (e.g.  by  shading  the  objea  form).  The  concurrent 
user  may  then  decide  that  irrespective  of  other  changes  made  to  Lhe  object  he  still  wants  to 
make  his  modificanon^.  The  incoming  version  is  ignored  and  user's  version  becomes  the 
latest  version.  Only  comrruned  modificanons  are  seen.  The  user  is  made  aware  of 
uncomrr^ned  concurrent  modificanons  The  user  may  also  view  earlier  versions  of  the 
objea.  Our  adaptadon  of  version  control  relies  on  the  user  to  resolve  version  conflicts;  the 
system  just  detects  jxtiennaJ  version  corilicts  and  notifies  the  user  of  their  existence. 

Modif\  -Mod:f\  Conf.ic: 

At  time  I  user  A  opens  the  form  of  object  "x"  m  modif>  mode.  All  sites  carrying 
representatives  of  "x"  arc  notified.  User  B  opjcns  the  form  of  objea  "x"  in  modify  mcxie  ai 
t-t-1.  He  is  notified  that  "x"  is  being  updawd  but  decides  to  go  on.  AU  sites  carrying 
represcntanves  of  "x"  are  notified  that  B  is  also  modifying  object  "x".  User  A  is  then  made 
aware  of  the  existence  of  another  modifier.  At  this  point  both  A  «fe  B  know  about  each 
others'  existence.  It  is  the  responsibility  of  the  user  that  commits  his  changes  last  to  merge 
the  other  user's  work  (assuming  both  are  authorized  users).  B  commits  his  changes  at  time 
t+2.  The  new  version  V,^2  ^  sent  to  all  sites  as  the  most  ctirrem  version  of  objea  "x".  A  is 
notified  of  the  arrival  of  the  new  version.  A  might  choose  to  ignore  this  version  or  compare 
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chances  l'  N',.-  t:  h:s  z'r.zr.z^>  and  merge  ir.tr  rv,c  appropnatei) .  Ir.  eiine:  case  user  A 
commr.!-  her  chances  a:  \~:  crea;j-.c  z  new  version  ^',.-j  Tnis  is  now  the  lates;  \ersior.  of 
objec:  a  .  1;  i>  broadcasted  tc  ai!  sues  una:  conain  representanves  of  "x"  and  installed  as 
ihe  late-^:  version 
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Figure  6-".  Resoivnc  Modif>-Modif>  ConfiiCT  using  Hybnd  Implcmentauon 

Read-Mod:'^  Conflicr 

Referring  to  fig~jre  6-",  an>'  reads  that  occur  before  time  t  will  result  in  version  "V^  being 
read.  Reads  ben>.eer  tune  :  and  t*2  will  also  result  in  \\  being  read  but  with  an  indication 
tha:  objer.  ' x"  is  being  modified.  A  user  reading  object  ' x"  bcrwecn  times  t*2  and  t-3  reads 
Vj^-.  A  use-  reading  objec:  'x'  a:  time  t-4  reads  version  Vj_^-. 


So  far  we  have  not  addressed  what  happens  if  a  modifv'  is  done  during  a  read.  Consider  the 
overlap  dcpiaed  in  Figure  6-8. 

User  A  reads  object  ' x'  ai  time  t.  Version  V(  apjpears  in  the  object  form.  At  time  i-l  user 
B  begins  to  modif>  object  ' x".  User  A  is  notified  of  the  fan  thai  another  user  is  modifying 
"x".  User  A  may  choose  to  terminate  his  read  untU  the  new  version  becomes  available  or  to 
continue  the  read.  Once  the  modify  is  committed  at  t+2,  user  A  is  prompted  to  refresh  his 
view,  of  object  "x". 
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Figure  6-8:  Resolving  a  Read-Modif>  CoaLiCt  usir.g  the  Hybr.d  LT.piemenracon 

Automatic  Transactions 

R-^e  rar.sa:r:or.s  need  ".o  acqj-s  ihe  appropr.ate  -c:id  ar.t  modiy_^  locks  bercr;  pertcrr^ir.g 
the  reaci  a.-c  uT.tes.  Ir.  mtcracuve  cansacuons  we  had  r.o  neec  for  'ead  locks  because 
users  are  always  allowed  :o  read  ne  most  rec«n:  corruTurted  version  of  a  object. 

Consider  firs:  categon.  Z  rules.  Locjong  ensures  iha:  the  r^e?  are  perfcrrned  a:orrjcal".>  ir. 
senalizable  crds:  No  rv-c  r^Is  rar.sac::or.5  ma>  ho'.d  ccr/.icung  locks  on  Lhe  same  objec:. 
Confliaing  locks  are  modii>-modi^'  and  read-modifv-. 

Category  1  rjles  are  created  slighLy  differently.  OrJy  read-modify  locks  are  considered 
conf:iring.  Two  category  1  rules  would  be  allowed  to  sLmul'LaneousIy  pjcrform  uheir 
append-orJy  'Ante.  The  resulting  versions  ntay  simply  'oc  merged. 

Deadlock 

In  the  case  of  interactive  ransactions  we  disregarded  deadlock  because  the  transacaons 

were  sL-nple  (i.e.,  only  co'uld  wnte  the  suigle  object  thai  was  read).  We  can  not  make  such 

an  ass'umpuon  m  the  case  of  automatic  transactions.  Consider  the  rule 
•  If  objea  =  task  then  set  taskmanager. count  to  taskmanager. count  +  1 

and  two  agents  corxurrently  applying  this  rule.  The  first  agent  Tl.  reads  object  O  and  then 
reads  and  writes  the  taskrr^tager  objea  Oj.  The  second  agent  tl,  reads  objea  O2  and  Lhen 
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reac  anc  u-r/.e  'jie  i3s'r:rr.2s\2cer  obiec!  O.      Figure  6-9  iUustrates^  2  pcssibJe  deadlock  tha: 


m2>  anse 

TI     R'O    RfO,)  WfOp 

t:  R.0-' R''C..w,o,i 

Tl  -  ReadJocki'O'  TZ  ■  ReadJock  0--i 

Grar.-.e::  Granjec 

Tl -Readjock(0,i  T:  -  ReidJcx±(0,j 

Gramed  Grarued 

Tl  -  Wnielock(0,)         T2  -  WntciockfO,^ 
Denied  Derued 

Deadlock 

Figure  6-9;   Rule  Execution  Deadlock 

We  co'jJd  choose  tc  prevcn:  deadlocks  is  such  cases  by  insisting  that  rules  obtain  al  locks 
in  an  ordered  mame:.  Lock  orderjig  avoids  deadlocks  and  enforces  a  senal  order 
execuaon. 

Another  possibiiin.-  is  tc  detect  deadlocks  using  timeouts.  If  execution  of  rules  have  been 
halted  for  a  specific  period,  Lhis  is  an  indication  of  a  deadlock.  If  a  deadlock  is  detected, 
rules  execuuon  need  to  be  rolled  back  and  reexecuted. 

In  executing  rules  the  latest  committed  version  should  be  read  unless  ii  has  been  locked 
(either  by  another  rule  or  a  user).  Tt\z  system  should  permit  the  user  in  case  of  an  overlap 
bcrween  interactive  read  and  a  rule  write  to  view  the  changes  made  by  the  rules  as  soon  as 
they  arc  committed.  Similarly  for  an  overlap  of  an  interactive  modify  with  a  rule  \*Tite,  the 
modifier  should  be  able  to  access  the  changes  performed  by  the  rule  write  if  he  %^ishes  to. 

To  summarize,  the  user  will  be  exposed  to  the  following  in  case  of  concurrent  access. 
•  Read-Modify  Conflict  -  A  reader  is  always  allowed  to  read.  TTie  most  current 
version  of  the  objca  is  returned.    A  reader  is  made  aware  of  a  concurrent 
modifs'  as  soon  as  it  is  knovvTi  to  the  svstcm. 
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•  Modify -.Modii>'  Conflic:  -  Tne  modine:  is  made  aware  of  a  second  modifier 
cnce  It  IS  kr.o'AT.  :c  's\t  s'<steT.  I;  :s  the  respons:bU:r.  cf  each  modif.e:  v^hsr. 
he  commits  to  merge  his  modificanons  wi^h  any  version  received  SLice  h-^s 
rr.ocry  :>€Zjs.-  Tr.-.i  r-arar.'.ees  '-".i:  al  •c.e\ir.".  changes  comm;r.td  so  :ar  are 
accounted  for  ir.  'Jie  latest  version  r:'  tr.e  ob-tc. 

•  Locking  -  Locking  may  oe  expjc:t-\  done  to  prevent  modify -modiiy-  conflicts. 
This  IS  done  m  cases  where  the  modifier  feels  his  changes  are  vital.  Locking 
an  object  w-X  no:  block  readers  who  are  always  pcrmmcd  to  read  earlier 
versions. 

•  Locking  -  Locking  is  impltcti^  done  b;-  the  system  when  rules  are  executed. 
Ca'^gor>  I  rules  arc  distmg-uished  ro— .  category  2  rjles  m  that  km  conflicts  m 
caiegor.  '.  rsLts  are  treated  as  appends  and  hence  need  not  be  blocked 

User  Interface 

Notificaaon  of  Lhe  existence  of  another  modifier  may  be  done  by  grev-rig  the  objea  form. 
Tnz  wser  reading  or  editmg  the  form,  is  hence  aw  are  of  other  modifier. 

A  user  m^ay  be  prom.pted  to  refresh  r-s  form  b>  blinking  the  refresh  command  on  the  object 
form- 
Adding  links  to  an  opened  folder  (i.e..  an  append  transacnonj  may  be  done  automaucaUy  by 
the  system.  n 

Implementation 

A  disiributed  Objca  Lens  enviror-ment  wuh  mulaple  representatives  of  objects  is  assumed. 
An  objea  manager  at  each  site  concrols  access  to  objects  ai  thai  site.  The  objea  mana.ger  ai 

each  site  maintains  Lhe  following  informanon  for  each  object: 

•  Locked  or  Unlocked. 

•  Be^ng  Modified,  by  whom  and  at  what  site. 
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•  Being  Read.  b>  v.norr.  and  a:  \^ha:  sue. 

•  Times:a.T.r  of  the  late?;  ^ersio^.  'uher.  it  uas  created 

V^lier.  ar.  object  is  accessed  in  modif\  mode,  a  requcs:  is  made  to  the  Object  Manager.  If 
the  object  :?  ioc^ed.  a:^e^-  is  d=la\ed  untJ  lock  is  reiease<l.  If  not,  Lhe  Object  Mar.ager 
venfie?.  l'"  :he  object  is  \xir.:  accessed  (read  or  modif>  '  by  another  user  If  the  obiect  is 
being  modifjec.  the  object  is  presented  with  an  indicauon  that  it  is  being  modified.  Tne 
user  is  hence  aware  of  the  oLher  modifiers  The  object  manager  then  broadcasts  to  other 
sites  Lha:  'user"  a:  'sne'  is  modif>-mg  object  "x'\  so  thai  other  object  managers  are  kept  up 
to  date  as  tc  who  is  modifNtne  Lhr  object.  They  will  in  rum  notif>'  local  users  of  a  neu 
modifier.  Once  the  user  decides  to  commit  his  changes,  the  objca  manager  verifies  that  no 
nev^  versions  have  beer.  rece:\ec  If  a  new  version  has  been  received,  the  user  is  Lnformc^ 
at  commit  time.  The  user  may  then  explicitly  and  interacnvely  merge  the  rwo  together. 
the  commined  version  will  include  changes  present  in  the  received  version.  The  object 
manager  installs  t^i..  as  a  nev.  versio.-!  uith  a  global  umesiamp  generited  at  commit  time. 
The  version  is  broadcast  to  all  sues  that  contain  representatives  of  objca  "x".  Receiving 
sites  will  remove  'user"  at  'sue"  from  the  list  of  modifiers  for  objea  "x".  The  new  version 
will  be  installed  as  the  latest  version  of  object  "x".  If  the  objea  "x"  is  being  locally 
modified  a  note  of  the  received  \e-sion  is  made. 

Similarly  for  a  read,  the  object  manager  checks  if  the  objea  is  being  modified  and  if  so  a 
shaded  form  of  the  object  is  presented  to  the  requester.  If  an  object  manager  is  aware  that 
someone  else  is  modif>'ing  an  objca  that  is  being  read  then  the  user  is  made  aware  of  thai. 

The  informauon  maintained  by  each  objea  manager  for  concurrency  purposes  is  not  large 
since  a  user  will  have  at  most  10  objea  forms  opened  ai  his  workstation  a:  any  one  time. 

Concurrency  control  for  automatic  transactions  can  be  integraicd  into  our  hybrid 
implememauon  by  adding  the  following  fearures: 
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•  L'sxz  LTiplici:  iockir.g  tc  force  ihe  scnaiLzaiior.  of  rjie. 

•  Deadio:>;  avcidar.ce  ?;.  preorderme  locks. 

•  Usir.c  -ne  latest  corr„-Ti:r.ed  version  of  ihe  oojec:  for  reads  l'^.  rjie  execution. 

Grar.uianr\  of  Lcct_L.". c 

Locking  is  bes  performed  at  the  object  level  Reducing  the  granulanry  to  the  field  level 
res'kilts  m  improved  concurrcncv  but  incurs  a  large  overhead  in  lock  table  maontenanc*. 
Locking  10  objects  u  ;ih  ten  fields  requL-es  a  1  jO  locks.  Moreover,  since  a  large  dczrez  of 
the  concurrenc)  concrol  is  performed  bv  version  conrol,  the  unproved  concurrency  due  tc 
decreased  granuian?.-  is  not  consideraoie  enough  to  justify  the  cos*^ 

P^JT.ar^  Co^^  Lockine 

Locking  IS  performed  using  the  prunar.  copy  approach.  The  choice  is  geared  by  ease  of 
impiementanon.  The  cop>  c:  the  object  a:  the  creator's  site  would  be  designated  as  the 
pnmaiy  copy.  Locking  requests  are  direaed  to  the  pnrr-ary  site.  Lock  conflicts  arc 
detected  there  and  relayed  back  tc  the  requesting  objea  manager.  Updates  are  directed  tc 
the  pnmarv-  site  and  then  propagated  from  there  to  all  other  sues  that  contain  representatives 
of  the  object.  For  locked  objects,  this  is  efficient  since  the  update  is  sent  wiih  the  lock 
release  request- 
In  case  of  version  control,  updates  arc  propagated  distnbutedly  to  the  relevant  sites.  It  is 
more  appropriate  not  to  have  a  centra]  controller  in  the  laissez-faire  case. 

To  summarize,  our  proposed  hybrid  locking  and  version  control  scheme  accommodates 
both  interactive  and  automatic  transactions.  Objects  nuy  be  locked  by  the  user  if  he  feels 
his  modifications  are  important  or  by  an  executing  rule.  Users  are  always  able  to  read  old 
versions  of  an  objea  even  if  another  user  is  concurrently  modifying  the  object  or  if  the 
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obiec:  i?  locked    Rules  SL-e  no;  able  tc  read  ar.  objec:  l^  i:  is  locked  by  anoihe:  rjle  or  b\  ihe 
use: 
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Chapter  7 
Conclusion 

7.1  Summary  of  Work 

Wc  have  in  ihe  earlier  chapters  examined  :he  vanous  approaches  to  building  Distributed 
Object  Lens.  The  four  mair  issaes  ue  s^ere  concerned  with  were: 

•  Disr:bu;ed  Object  Lens  .-Vrcr-tecr-rs 

•  Creation  of  Share:!  0?jec'^  ir.  Disnbuted  Object  Lens 

•  Protecuon  of  Shared  Objects  l".  DisL-.buied  Object  Lens 

•  Concurrency  Conrro!  and  Upxlaie  Propagaiion  in  Distributed  Object  Lens 

For  each  of  these  issues  we  will  present  the  alternatives  and  summarize  the  tradeoffs.  V»'e 
will  then  present  our  recommendations  ihe  best  option  for  Distributed  Object  Lens. 

Distributed  Object  Lens  Architecture 

The  three  options  we  examined  were: 

L  Message-Based  System 

2.  CcntraLized  System 

3.  Distributed  System 

The  rr^s  sage -based  system  described  an  objea  initiation  scheme  thai  fits  well  with  Objea 
Lens's  extensive  use  of  messages.  However,  u  fails  to  be  comprehensive  enough  to  support 
a  system-assisted  update  propagauon  and  concurrency  control  scheme.  The  system  might 
result  in  an  unaccountable  number  of  object  copies  being  present. 
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The  centralized  opnor.  is  arn-2r::'>e  because  of  us  SLTiple:  concurrency  conro!  scheme  and 
SLTipier  rS.t  resoiunor.  scheme  Tne  first  clarr:  is  valid  only  if  we  decided  or.  i.  crainonai 
concurrency  conrrol  scheme  le  c  .  lockinc  or  amestampmg).  The  concurrency  scheme  mos: 
suuabie  for  Disr:bj:ed  Objen  Lens  was  the  proposed  hybnd  scheme  of  locking  anc 
versions.  Our  scheme  assumes  that  more  than  one  cop\  of  the  obiec;  exits  Ln  some  state  or 
another  a:  one  time.  Tnis  leaves  us  with  the  centralized  with  caching  opuon.  Ln  fact.  Lhe 
"centralized  with  caching"  option  is  equivalent  with  respect  to  our  proposed  concurrencv 
control  scheme  tc  the  disnbuted  option  with  pnmarv'  copy  update.  Despite  the  unproved 
p>erformance  that  car.  be  attained  r>  caching,  the  bottJeneck  imposed  on  the  system  b\  t-ne 
centra]  site  still  exists.  Tne  centralized  cached  approach  implies  a  central  rule  resolution 
paradigm.  Ail  roles  are  resolved  at  the  central  site,  and  the  objects  that  match  are  reromed. 
Note,  however  that  e%en  m  the  centralized  case,  pnvate  objects  are  located  at  the  local 
worksatation.  hence  any  rules  that  consider  shared  as  well  as  private  objects  need  to  be 
applied  at  the  lozzl  wcrkstanon  for  the  personal  objects  and  ai  the  central  site  for  shared 
objects. 

Much  of  the  comp!ex!t%  in  Lhe  distributed  approach  is  the  due  to  complex  concurrency 
scheme  and  com.piex  rule  resolution  scheme.  As  mentioned  earlier  performance  of  the 
concurrency  scheme  is  somewhat  the  same  for  the  centralized  with  caching  and  the 
distnbuted  approach.  The  rule  resolution  paradigm  on  the  other  hand  is  complex  because 
objects  are  distributed  over  the  system.  Fully  redundant  replication  will  eliminate  this 
problem  but  introduce  a  large  overhead  to  propagate  updates  and  a  large  increase  in  the 
amount  of  memorv-  space  needed. 

We  have  eliminated  concurrency  control  as  a  key  consideration  in  deciding  between  the 

"central  with  caching"  and  the  "distributed  approach".  The  key  considerations  that  remain 
arc  rule  resolution  and  contenuon.    Rule  resolution  may  be  simplified  in  the  distributed 
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approach  if  we  cor.s:der  ihe  fuJJ>'  redundant  case.    The  fully  redundant  case  requires  more 
memon.  space  to  store  a:  each  v.orks:ai:on  2I'.  objects  used  whether  personal  or  shared. 

To  summanze.  i".e  k?>  issues  m.  c.sz\d-^s  berv-eer.  tr.e  isrr.buted  and  cenralized  approach 
are: 


Csr.~2us.td  'A  :■-"!  cac: 


BorJeneck 

Simple  Rule  Resolution 


Disinbited  Arrroach 

No  contention  a:  central  sue 

Complex  Rale  Resoluuon 

Simplified  in  FuUy  Redundant  Case 

Tradeoff  between  <complex  rule  resolution>  and 
<lncreased  memor>  Space  and  Lncrtased  Locking  and 

L'?ca;e  Prorasatior.  Overheads 


Creation  of  Shared  Objects 

We  proposed  two  ways  of  making  an  object  shared.  The  ongmaior  can: 

1.  insen  a  reference  to  it  in  a  Mail  Message. 

2.  insert  a  link  to  it  in  a  shared  object. 

We  concluded  Lha:  Distributed  Object  Lens  -ttdtd.  to  supper.  boLh  methods.  Tne  first  was 
esscnual  to  initiate  sharing  of  a  parent  objea.  T^e  second  was  narural  for  sharing  of  child 
objeas. 


Protection  of  Shared  Objects 

The  two  options  we  examined  were; 

1.  Capability -Based  System 

2.  Access  Control  List  Svstem 
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The  proposed  scheme  is. 

•  Hsbnc  c:  Capab^;r\ -based  anc  Access  Cona-o!  Lisi 

A  capability -based  protecxior.  mecharusrr.  is  the  namraJ  choice  for  Distributed  Objea  Lens. 
Object  Lens  is  a  uzt.t: -or.sr.-.tz  s>s:err.  ir.  the  sense  that  users  need  to  have  links  (unique 
objea  ids)  to  objects  before  they  can  access  them.  It  is  thus  reasonable  to  augment  the 
unique  object  id  with  the  relevant  fields  indicating  read,  write  and  delete  access. 
Capability -based  SN'stetr.  has  its  pitfalls  (uncontroUcd  access,  rcvocarion  of  access). 

An  access  control  list  s\sierr.  uould  mean  a  tremendous  overhead  in  maintaining  lists  for 
each  object.  A  permissive  Lis:  would  be  too  long  to  maintain. 

We  propose  to  use  access  control  lists  in  a  restrictive  manner  to  suppon  the  capabilir.-- 
based  s}.-stem.  T>J3  hybrid  s>stem  allows  users  access  tc  objects  if  they  have  the  correct 
access  rights  as  indicated  ir.  the  unique  objea  id  and  if  they  are  not  restnaed  by  the  list. 
TTie  overhead  incurred  here  would  be  less  thar.  the  permissive  case  mainly  because  of  the 
size  of  the  list  Tlie  rescr,cti\e  list  would  be  easier  to  maintain.  The  list  is  specified  by  the 
creator  by  indicating  auLTonzed  users  b\  usemame  or  by  formulating  a  set  of  rules  that 
specifv  auLhorj^d  users'  attributes. 

Concurrency  Control  and  Update  Propagation 
The  four  options  examined  were: 

1.  Simple  Two-Phase  Locking 

2.  Basic  Timestamping 

3.  Distributed  Certificauon 

4.  Version  Control 
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The  proposed  scheme  is; 

•  Hybr.w  o:'  lock^-.:  ar.d  '.ersior.  ;or.ro! 

Users  LT  Distributed  Object  Lcr.s  L-/^rarj'.  ei>  ed;:  objects  for  long  pcnocs  o:  time. 

Two-Phise  Locking  resolves  corilicts  by  aiiowmg  at  most  one  user  a:  a  time  to  modify  an 
object.   Tr^s  mear^  tr.a:  the  second  user  his  to  wait  (perhaps  for  a  long  tme).    Locking  is 


Basic  Timestamping  scores  vi,orse  s;r.:e  tr.e  use:  is  not  aware  of  other  concurren:  users. 
The  user  :s  notif.ed  that  hjs  work  mignt  res'ul:  in  a  coriiict  and  thus  rejcr.ed  v.  hen  he  is 
ready  to  commit  the  changes.  Such  i:rir.endl_-.ess  would  no:  be  tolerated  by  an  Object 
Lens  user. 

Distributed  Certification  scores  badly  as  well.  The  user  faces  the  same  urir.endimess  as 
the  Timestampmg  approach.  It  is  a:  com-m::  tme  that  a  user's  mocjifications  are  rejected 
because  of  a  coniiict. 

Version  control's  mam  artractiveness  is  its  laissez-farr  att:njde.  Concurrent  users  are  free 
to  make  then  modificaiior^s  and  hence  creaie  new  accessible  versions  of  Lhe  objea.  These 
versions  can  be  then  merged  to  create  the  new  -jrrent  object.  This  scheme  however  fails  to 
resolve  senaiizable  corilicts  imodificauons  that  are  dependent  on  a  concurrent  users' 
work). 

We  hence  proposed  a  hybrid  scheme  thai  com.bines  locking  (explicit),  notificaaon  and 
version  control.  Explicit  locking  is  provided  for  serializab'.e  contlicts.  It  is  the  user's 
responsibility  to  assess  his  changes  as  vital  and  hence  lock  the  objea  making  it  inaccessible 
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to cLneri     1:'  tr,e  oner:  is  aireac\  locked,  iher.  oLner  users  w.  ai:.  trusiLng  Lhia:  changes  made 
to  the  object  are  yr.il    No:j"ica::or.  u  ams  users  of  o*-hcr  concurren:  users  in  Lhe  laissez-faire 
environrr.en:     Trj>  m^cificauor.  rr.:zh:  lead  to  informal  communicatior.  berwecn  ihe  users 

tc  de:£rrr.:r.t  ar.v  possibilirv-  of  cor_f.icis.  At  comrru;  time,  the  user  is  prompted  to  merge 
any  pending  \ersions  it.z:  ha\e  beer.  r^:f.\td.  since  the  user  began  his  work. 

7.2  The  Proposed  Distributed  Object  Lens 

We  choose  tc  descr.^e  uie  disrributed  approach  to  implementing  Distributed  Object  Lens 
because  of  Lhe  genera:;:>  cf  the  solution.  A  speciaj  case  of  this  is  the  'centralized  wiLh 
caching'  approach.  Tne  system  is  depicted  in  Figure  7-1. 
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Figure  7-1:  Dismbuied  Objea  Lens 

Shared  objects  would  not  be  replicated  at  each  site,  however  several  object  instance 
represcntarives  of  an  object  would  exist  in  the  network,  probably  at  sites  where  they  are 
most  used.  Hence,  some  object  access  would  be  remote  and  others  would  be  local.  'We 
might  in  some  cases  choose  to  mai:e  this  apjparcnt  to  the  user.  System  wide  object  ids  are 
indicative  of  the  object's  location,  the  version  nme  of  creation  and  the  access  rights  to  the 
object.     Since  we  allou   replication,  a  catalog  is  maintained  ai  each  object  manager 
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Lidicatirig  the  o-Jne:  iocatior.s  of  rep:essn:a:;ves  of  shared  objects  stored  Io:a]I>.  Tn:s  :s 
needed  to  er.sure  'j-.a;  -pdaies  are  propagated  to  those  sites  Updates  r.eu  versions)  aie 
prora£a;ed  b^  the  5::e  uhere  the  jrdate  occurs  Distr.b'jted  jrda'.e  rro'oatatior.  is  used  ir. 
case  of  version  cono-oi  anc  pnmar>-  copy  iocking  and  upxdaie  m  case  or  iocKng. 

Tne  Object  Mar.age:  u^  have  the  foliowir.g  duaes: 

•  Trar.slatior.  table  of  the  system  wide  ids  generated  by  the  objea  manager  and 
the  L'-.temai  ids  Lndicating  the  physical  location  of  the  objea  in  memory 
generated  by  the  local  object  ser.er. 

•  A  list  of  all  objects  currently  being  viewed  at  the  local  w  orkstauon. 

•  A  lis:  of  all  locked  objects. 

•  A  list  of  an>  received  versions  of  objects  bei-.g  viewed. 

•  .A  catalog  of  local  snared  objects  and  their  ouher  sites- . 

•  Tne  capabilirv-  to  reduce  access  modes  of  an  object  given  the  system,  wide 
objea  id. 

•  Maintain  restrictive  access  control  lists  for  shared  objects  at  the  local  site. 
Tnese  need  to  be  replicated  ai  each  site  where  a  copy  o:  the  object  exists". 


'This  ciuJog  could  be  mainumed  centrally  for  all  objcc:  maaagen 


^Agaic  such  a  hst  could  be  maiDiained  centrally  to  mminuze  on  space  used  aod  updaii  propa^anoo  is  case 
of  change 
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7.3  Direction  of  Future  \\ork 

Vv'e  f:e'.  Lha:  ir.  o-oi  quest  for  ar.  obje:;  sharing  scheme  for  Object  Lcr.s  v-e  have  shed  some 
light  or.  the  relevant  fearures  that  influence  the  design  of  a  concurrency  concoi  scneme  ir. 
an  object-onenied  h>-penext  system  that  incorporates  both  user-driven  long  transactions  and 
shor.  lived  automati:  rransactionv  Our  scheme  differs  from  those  proposed  earlier  in  that  it 
allows  for  rephca5  and  versions  of  an  object  to  exist.  It  also  pwrmits  a  user  to  always  viev. 
the  most  recent  version  of  an  object.  We  propose  that  it  is  enough  to  warn  the  user  of  a 
potenuaJ  conf.ict  and  lease  it  to  the  user  to  resolve  the  conflia  by  merging  relevant 
versions  together  It  is  wonhwhile  to  explore  the  possibilities  of  automauc  merging  by  the 
system  using  a  sp)ecific  set  of  rules. 

Initiating  sharing  using  mail  messages  is  another  feature  not  common  in  hypenext  systems 
This  is  character.s::c  of  our  systerr.  because  of  us  integration  with  an  clecn-omc 
system. 

Protecting  object.'^  is  ar.  issue  that  has  not  been  seriously  addressed  in  the  h\-penext 
commuTury.  \^'e  feel  that  thus  is  important  in  a  distributed  environment  where  object 
sharing  is  possible. 

Out  examination  of  object  sharing  in  Objea  Lens  reveals  a  class  of  infomiarion  shanng  and 
collaboranve  applications  which  have  less  stringent  concurrency  and  consistency 
requirements  for  some  transactions  and  objects  they  support  We  identified  those 
transactions  as  long  interactive  transactions  thai  involve  editing  object  forms.  Multiple 
users  in  such  applications  need  not  see  consistent  copies  of  the  objea  as  long  as  they  are 
aware  of  the  existence  of  other  versions.  Moreover,  a  user's  role  has  expanded  to  include 
explicit  merging  of  different  versions.  These  applications  need  to  also  suppon  shon 
automatic  transactions  thai  rcquu-e  to  see  consistent  copies  of  the  objea.    Concurrency 


conn"ol  IS  much  more  s~j-.geri:  m  this  case  I:  is  not  sufncient  to  provide  concurrency 
cor.trr!  rcr  one  set  c!  ~ar.5ac;ions  or  another,  but  rather  Oiir  svstem  must  oro\'.de 
concurrency  conroi  scnemes  to  accomjnodate  ix)th  ry-pcs  of  transacnons. 

Tne  bcnents  of  a  less  stringent  consistency  and  conc,irrency  requirements  Lndicate  that 
future  cooperat'.' e  work  applicaiicns  should  aliovi.  uorkgroups  to  choose  berue«n  snc: 
concTirrency  conrol  provided  by  lockir.g  and  more  flexible  concurrency  control  provided 
by  version  merging. 

This  work  has  left  out  m.an>  of  the  implementation  details.  It  was  successful  m  prcsenor.g 
the  design  space  for  D;str.b-ted  Object  Lens  and  m  recommending  schemes  for  object 
creation,  object  protecuon.  concurrency  concrol  and  ujxiaie  propagation.  Tne  mie  test  of 
these  schemes  is  l-.  tr.e  actual  implem.entation  c:  the  EXsrnbuted  Object  Lens  prototype . 
Depending  on  the  choice  of  a  pla'Jorm  for  Object  Lens  a  more  detailed  analysis  of  Lhe 
foUowmg  nee-ds  to  be  performed  l".  the  foUowmg  area  d-urj~.g  the  implementation  phase: 

•  Objea  Deletion. 

•  Distributed  vs.  Prur.ary  copy  update  li  the  case  of  version  control.  We  have 
outlLied  a  disnbuted  opuon  whuch  co'uld  suTiply  be  specialized  to  Lhe  prjr.ary 
copy  option. 

•  Rule  resolution. 

•  Recovery-. 

•  Version  management.  ^ 

The  pjower  of  coopcrarive  work  applicauons  is  only  realized  with  the  availability  of  object 
shanng.  We  hope  thai  Lhe  first  prototype  of  Disributed  Object  Lens  would  illustrate  the 
imponance  of  scmifonnal  systems  to  acbueve  sharing  of  scmistnictured  knowledge  and 
information. 
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